Beauty Is Our Business : A Birthday Salute to Edsger W. Dijkstra (Texts and Monographs in Computer Science)
ec1.images-amazon.com
ISBN: 0387972994
This book is a birthday tribute to Ew Dijkstra, with about 25 articles written by friends.
The book title comes from something written or spoken by Ew Dijkstra. The 'our' refers to computer scientists (with the EMPHasis on science).
David Gelernter said in "Machine Beauty - Elegance and the Heart of Technology.":
Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity.
- - Beauty must be sometimes complex, see fractal designs. Clouds, flowers, cells imitate those designs it seem -- Michel Dauchez.
- but the very nature of fractals is that they are simplicity within chaos. - Joachim Noreiko
BEAUTY IS UNDEFINABLE. LEAVE IT ALONE.
I feel that the title of this book is equally applicable to software construction. Software engineers should be more concerned with beauty. It pays off in the long run. -- Marnix Klooster
I completely disagree. I know I've done something right when the code turns out beautiful. But ... beauty is an emergent property. You focus on the other stuff (functionality, performance, maintainability, ...) and, when you get that stuff down, you get beauty for free. Such a deal ... -- William Grosso
I agree with both of you. You can use beauty as a metric of your work. If it's beautiful you've done it right. If it's not it needs fixing. -- Anders Chrigstrom
Also agree with both. An interesting property of Extreme Programming, since we go to code so quickly, is that we get to see the beauty emerge quite often. We even wind up with beauty where we never "planned" to have it.
But we don't experience that incredible rush you can get when suddenly you "see" the entire solution in your mind. We also miss the incredible headache you get when you try to get the thing you saw to actually work. -- Ron Jeffries
Beauty can't be a short-term goal, but it can be a long-term goal. In other words, I don't say on a minute by minute basis, "let's make this more beautiful". I'll say things like "let's get rid of this case statement" or "let's get this test to work". But I might say at a review meeting "I'm not surprised you are finding a lot of bugs in that module, it is the ugliest part of the system. It needs to be refactored pretty heavily."
To me, beauty is a sign of good software. When I can understand software easily, when its structure matches its function, it seems beautiful to me. I agree that Beauty Is Our Business, or at least part of our business. -- Ralph Johnson
The Architect of course!.
No, but seriously 'beauty' is a large part of a (building) Architect's role for me. This may be a somewhat old fashioned view but beauty (or call it 'Delight' as in the Vitruvian triad mentioned on Good Architecture) seems to me to be a large part of the distinctive contribution brought to building (environmental) design by Architects.
Of course Architects are intensely involved in 'firmness' - structure, construction (making things stand up and keeping the water out!) - and 'commodity' - fitness for purpose, functionality, usefulness - but so to are other members of the overall 'buildingteam'. However, it is the combination of these aspects with 'beauty', the marriage, ideally, of the prosaic with the 'sacred', or at least with the 'delightful' that other members of the team usually are not too concerned about and are not trained to consider.
Of course I'm taking about 'Beauty' in the widest sense, but obviously in built architecture this includes the traditional aesthetic qualities of form (shape), colour, space, line, texture, light etc. Beyond these qualities 'beauty' for this argument might also encompass the ideas of the building, the messages communicated by the building, the 'meaning' of the building beyond the prosaic necessities.
Now, for me, if software is to really appropriately use the Architectural metaphor, there has to be some inclusion of, some reference to 'beauty' as part of the product (be it code/programmes/whatever). This comes back to the whole essence of who an Architect is and what he does. As I've said elsewhere
(eg Chief Architect) the Architect can't just be a 'manager' or a 'technician'.
Maybe 'beauty' in software needs to be defined or re-defined. Maybe there are analogous qualities/aspects that should be considered: but that's for you guys to sort out!
- - A written piece of software is exactly the same as a mathematical demonstration they said. And maths are a paragon of beauty they said too. Let's keep on programming! md
Isn't beauty quite a subjective thing? It's hard for me to imagine admiring a piece of code and thinking it's beautiful, if not for the fact that its structure and style will somehow make my life better. I can't imaging saying "this here piece of code is quite beautiful, BUT ... ". Therefore, beautiful code is code that has no but.
Is beauty anything more than the subjective experience of verifying the qualities we want? -- Walden Mathews
'Truth is beauty, beauty, truth' -- John Keats
In a kinda EWD way, the beauty of software is found in the understanding incarnation, not the source, executable, or executing incarnation. Some people think bats are beautiful. -- Bob Bockholt
I have no problem saying (for example) "Lisp is beautiful in a mathematical sense, but I'm not a mathematician, don't think like one and prefer Perl"... But it's true that the thing I'm thinking about here is significantly bigger than "a piece of code" - I wouldn't think about code, as such, being beautiful... -- Anonymous Donor
Beauty can be defined as that which, being apprehended, pleases. Accordingly, beauty straddles both the objective (there is an object apprehended) and the subjective (the delight is within the observer).
I believe there are some things which, being apprehended, ought to please - things, in other words, that are objectively beautiful. I also believe there are things that are objectively ugly. In practice, I think most things we apprehend, including software design and code, are composites of the beautiful and the not-beautiful. Depending on your preferences, a composite could be said to be beautiful if it contains any beauty at all, or only if it has a reasonable amount of beauty, or only if it is mostly beautiful, or only if it is thoroughly beautiful (laxism, probabilism, probabilioralism, and rigorism, for those who like terms like that; when I'm informal, I'm a probabilioralist).
I think software has enough measures associated with it (does it run, does it work, how much does it cost, etc.) that it's reasonable to say that certain features of the code ought to please. (Simplicity, for example, since you aren't doing much apprehending if you're looking at code you can't understand.) At the same time, I don't think pleasure is something we need to seek in constructing software, particularly in situations where hard engineering concerns (does it fit in memory, is it fast enough) dominate decisions. And I agree with those who have suggested that beauty is a result of good software development, not its goal. -- Tom Kreitzberg
- - if the code is quite readable, it will help easy maintenance (or repairs, is it the word ?). But the fastness might not be there. The code must also be beautiful in action: it must work faster than hell -- md.
beauty is a result of good software development, not its goal
So Beauty Is Our Business but it's not our goal? I'd like to pry at that a little because I sense that it carries a smidgeon of shame, like wearing a petticoat while programming (which works, by the way). Creating software is such a feedback intensive thing that people who feel Beauty Is Our Business are constantly guided by the beauty level of what they have so far. Maybe that goal's in the closet, but it's still a goal. And of course, I'm only talking about code beauty here. There's even stronger reason for the external appearance and behavior of software to be beautiful. Too obvious to explain. Thank you, -- Walden Mathews
[After writing the above, I realized that maybe surprise is a part of the beauty discussed on this page. Sometimes doing a diligent job of analysis yields an elegant result that does not fully radiate beauty until fully assembled. I've had that reaction to things I've built well. But I'm not likely to have it as strongly again, since I've been there before. It's like magic -- try to understand it or expose it fully and you risk giving up the thrill of experience forever. Is this perhaps the bridge between my "intentional" beauty and the serendipitous beauty described by others here? -- wm]
Since I don't see beauty as the goal of software development, I don't see it as its business, either, so I wouldn't agree that I carry a smidgeon of shame about making software beautiful. But I'll temper my comments by allowing as how everyone who creates anything ought to prefer, all else being equal, to create something beautiful rather than something not beautiful. But that's not a software thing; it's a human thing. -- Tom Kreitzberg
Maybe the word 'beauty' means different things to us. The kind I'm talking about is not optional in any software product of critical size, importance or life expectancy. If we've recognized that it's desirable, then why is it taboo to make it a conscious goal? What is there to lose? Can beauty not be directly pursued? Can false beauties lure us astray like Sirens? Do we simply not know what we are looking for? Does it take high expertise to guide the search? If so, perhaps that's Martin's Architect (above). -- Walden Mathews
I think that something this whole discussion about Beauty is missing (as is the companion Beauty Aint My Business No Sir topic) is that those who apply the word "beauty" to any essentially technical pursuit, whether it's bridge-building or solving differential equations or software engineering, have a passion for that pursuit. It isn't about practitioners vs. theorists. It isn't about scientists vs. engineers. It *is* about professionals vs. hacks.
It speaks of people that go beyond just Getting the Job Done, to those who take a great deal of pride and satisfaction about Getting the Job Done with a Style and Clarity and efficiency that they interpret as something that displays Beauty.
I remember a story about a Greek sculptor who was retained to carve some figures to appear on the facade of the Acropolis. When he submitted his bill to the city fathers, they were outraged when they saw the total, and realized that the sculptor had sculpted the figures "in the round", rather than simply carving the front, their only visible surface. When they complained, saying "Why did you carve them in the round - no one will see the backs of those figures?", the sculptor replied "The gods will see them".
That's the way I want to think about my code, and the way I want my close associates to think about their code. The results for us, for the client and for our reputation will reward us, even if only the Gods see our code. -- Steve Sawyer
Beauty is deprecated in engineering pursuits because the practical must rule -- what use is a beautiful bridge that falls down, or a beautiful program that runs too slowly? But, as computers become increasingly more capable of running anything we care to write, beauty becomes the most important thing. That's because beauty is another word for this fits well in my head. And code that fits in your head is more maintainable than code that doesn't fit in your head. Maintainable code is very practical. So don't let anyone tell you that creating beauty is wasteful. Creating beautiful code is as practical a pursuit as there is.
- - But what if - and when will that fall upon us - computers begin to create beauty themselves, or practise arts. The day is near -- md.
Think of something that's ugly but it works. Maybe you have an example of such a thing in hand. Now, what's ugly about it? Is it ugly because it's engineered, or is it ugly because it's badly engineered, and about to cause problems?
"It's ugly but it works". I wrote that in a comment once, in an assembly subroutine that was being particularly clever, saving a few instructions over the straightforward solution.
As it turned out it didn't work after all (why are you not surprised?). Revisiting the code I couldn't even figure out what the clever trick was that was supposed to be at work. I rewrote the subroutine in clean, straightforward fashion and it worked.
Beauty Is Our Business is for me an empirical observation, not a philosophical position. When a junior programmer tells me that it's ugly but it works, it is very tempting to reply simply: "No it doesn't."
----
''I would echo my italic predecessor. In building one must think about the fact that people will use it. If a building is beautiful to its users then it will uplift them. This is communication. Additionally there is design beauty, the way it works. I think we're talking about the latter.
Its not about looking good, its about working well. Internal beauty communicates itself as naturally and easily as possible. If I build an optimised routine it becomes 'ugly', a 'beast'. This is itself an aesthetic but a refined one. I love a brutally condensed piece of logic, but then I'm a sick programmer; some people like the designs of the Bauhaus school, and they are all sick architects ;-)
If there is a conventional beauty in programming then I think it is an internal, structural quality, that communicates its function in a natural way. I suspect there is a Golden Mean of code beauty that someone will establish. Perhaps if we analyse systems numerically against a peer group of programmers we might find these features, the depth of hierarchies, the length of methods, the complexity of data structures. Of course this will not encode beauty or even define it, but like the Eastern forms it may provide a structure upon which programming beauty may be both individually creative and widely understood.'' -- Richard Henderson
Beauty is about demonstrating surplus of capability and other goodnesses. I'm ripping the roof overhangs off my new house addition and re-sheathing them with the beaded boards of the original (Victorian) design. It doesn't make the house work better; it doesn't make it more maintainable. It's a statement of devotion. It says "We love; We are here; We can do". It comes from the deepest instincts to thrive. -- Walden Mathews
- - Animals are beauty and live in beauty, they can't imagine any opposite side in their world. We have to learn beauty as we are learning creatures. When our job is to code and encode and code let's also create beauty in this world -- md. (and for those whose it is of no interest : it will fall upon you one day)
: "things, in other words, that are objectively beautiful", you wrote this, - - no, as (or) if it has to be learnt. See also Beauty - Is - Discovery when I dare contribute to that subject -- md.
An interesting way to approach Software Beauty is to think in terms of the study of Aesthetics in other fields. Is this software pleasing to the senses? Does it expand our sensitivities?
Paul Graham about beauty: www.paulgraham.com 
-- Milan Maksimovic
The Wiki Pedia on Aesthetics: en.wikipedia.org
I've rejected design proposals with the justification "It's ugly" and put forward others with the sole justification "It's the correct solution because it's the most elegant". I don't see this as being bad at my job, I see it as lacking the ability to translate my experience with good and bad designs into more useful feedback that will explain why something is ugly or elegant. My inability to explain doesn't change the correctness of a solution; it can unfortunately sometimes impact my ability to argue for the correct option. When this happens I tend to use my perception of beauty as a reason to seek arbitration. So beauty may not be our goal, but it is a fine indicator of how well we're doing. --Stuart Scott Having just found the Unconscious Competence page, is it too boastful to claim that's what I'm describing here? -ss
Not at all, that's exactly what is at work here. -- Doug Merritt
See also Beauty Aint My Business No Sir
See original on c2.com