Slashdot Mirror
Software Aesthetics
cconnell writes: "Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame. This article is a challenge to engineers, managers, executives and software users (which is everyone) to raise our standards about software. We should expect the same level of quality and performance in software we demand in physical construction. Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty." We had a good discussion on a related topic half a year ago.
- Meet user requirements
Which doesn't necessarily mean it has nice and pretty code. If you have time, you are doing yourself a favor by designing it, but you can't lose track of the purpose of what you are doing, which is to get something working.Most techniques for designing or building software (e.g. patterns, processes) all serve to help you avoid bugs, which is to say more efficiently build software that meets user requirements.
http://www.naildrivin5.com/davec
The bridge analogy you mention is frequently quoted. And I agree, standards in software design & implementation need to improve - particularly in the shrink-wrap world (I happen to think that in-house bespoke systems are generally better). But the standard response to your standard analogy is that any non-trivial application is hugely more complex than a bridge.
The design of a bridge is basically the extrapolation of a few well known engineering principles to the scale you want. It has 2 requirements : (1) It must reach from one side to the other and (2) it must not fall down. You may have noticed that software is not like that
I remember reading a quote from a famous software scientist (I forget who, maybe Turing?) who said (and I paraphrase here) that we shouldn't be teaching our your computer scientists maths, physics, engineering etc, but rather art and biology. Because programming is an art, it's the creation of something from your own imagination, not like engineering which is simply applying rules. And once created, any large application behaves far more like a living organism than a machine, it grows, it evolves and (often) it gets ill. I always liked that idea
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
Personally, I found Donald Knuth's Literate Programming as well as the Practice of Programming to be wonderful resources for writing better, more beautiful code.
This article is very interesting; the idea of code as an art form isn't new, but this article certainly is aggresive in encouraging it.
But what about "Extreme Programming" - doesn't it encourage the same thing, in terms of self-commenting code? Or does its specific nature essentially negate that aspect?
Attempting to compare software engineering to building a bridge or constructing a house is flawed. The reason bridges are built to such exacting standards is because if they aren't, they FALL DOWN. They cease to function. 100% failure. Poorly built software, on the other hand, can still work well enough to be usuable. It may imperfect at some tasks, but perform adaquately at others. If it were true that anything less than a perfectly engineered piece of software would simply fail to compile, then we'd all be writing perfectly engineered software.
An additional flaw in the analogy is this: The function, or use, of a bridge is quite clear: Extend a roadway over an otherwise impassable divide, such as a river. Simple as that. But deciding what the function or use of a piece of software is much more difficult and complex. Software is told to do many things, and the things it's supposed to do changes over time.
I'm all in favor of well designed software. But his vision is more utopian than useful.
Every extra day that I take to plan, every minute I spend thinking about design, and every extra line of code I write to make my software more pleasing is another line that could add more functionality, another minute wasted not producing something tangible, and another day that I need to be paid.
That is an absolutely absurd statement. Every moment spent in planning, review, consideration of potential problems, creation of general-purpose solutions, and documentation of architecture pays for itself many times over later in the development, validation, release and maintenance cycles. Failure to undertake sensible planning activities early in a project leads to massive schedule delays from forced late-game rearchitectures that would have been headed off by early consideration, review and communication.
Software engineering is the only engineering discipline in which the practitioners are permitted to indulge themselves in work without planning or review, and that's the #1 reason that software sucks.
Tim
Very perceptive...coding software is like crafting a cabinet. However, designing a cabinet is art...and so is designing software.
Try expressing an emotion in C++. It cannot be done.
jesus->loves(you); // Sarcasm, for the humor impaired
Regardless, art doesn't just express emotion, it inspires emotion. And trust me, I've had (mostly other people's) C++ code inspire some pretty horrific emotions. ;-)
Good design and coding, on the other hand, can truly be things of beauty, regardless of language.
Please think before repeating these banal opinions that software is art. It just isn't. Deal with it, and if you want to be an artist, learn to paint.
Spoken like someone who just doesn't really comprehend software design, or why one design might be more elegant than another. I suppose you don't think mathematics is beautiful either...
186,282 mi/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
The cited article doesn't say anything profound. (I got particularly worried when he said, "global variables and GOTO statements ... may be exactly what the software needs to marry form with function," and when his example of beautiful software turned out to be a fragment of Visual Basic. "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." --said, tongue at most partly in cheek, by Edsger W. Dijkstra, in "How do we tell truths that might hurt?")
... and there are other programs about which we can say, 'wow, who wrote this!'" He suggests how you can recognize software with The Quality: "every part of the code is transparently clear -- there are no sections that are obscure to gain effciency; everything about it seems familiar; I can imagine changing it, adding some functionality; I am not afraid of it, I will remember it." There are even suggestions, not how to make more beautiful software, but how to learn to do so.
Richard P. Gabriel (whose essay on "Mob Programming" was recently discussed on Slashdot) has a far more profound take on the subject. He has a summary of Christopher Alexander's work on architecture and "The Quality Without A Name," and how it relates to software; you can read the PDF version on his Web site, or Google's cached text version.
Excerpts: "there are programs we can look at and about which we say, 'no way I'm maintaining that kluge'
Gabriel helped start the "patterns movement" in the object-oriented community. Aside from the Design Patterns book, patterns (and especially generative pattern languages) have yet to make a significant inpact on software development. Maybe someday, maybe not.
Stupid job ads, weird spam, occasional insight at
I suppose that might be true, but I would venture that not everyone is in the same boat. I, for example, AM paid to write pretty code. My job is to come up with relatively simple perl scripts (modules) to solve various problems that Dartmouth's website users have. (For example, I wrote a quota module to help people verify that files they want to write to disk will fit within their alloted disk quota.)
I have NEVER turned in to my boss anything but well-documented, well-commented, readable code. I don't do this out of respect for my users; frankly, I know how to use the software and if they don't they can read my docs and try to figure it out. No, I do it for the other schmucks like me. At some point, my boss will probably tell his next lackey to add some little feature to one of my modules, as he's asked me to do with some older programmer's works. And it's DAMNED IMPOSSIBLE to wrap my head around code which is all mixed up. I comment for other programmers. People who might need to sink their hands into my code.
Paying me now to write comments and format things well is worth it for the added speed with which the software will be maintained in the future. So for me, and I'm sure most of the code jockeys on Slashdot, the "real world" is one where software is written, THEN MAINTAINED. Beauty is part of maintanence.
Its messy if you do not know what you are doing. Just like coding or debugging.
Biological systems are actually incredibly beautiful well structured, and in many cases optimized for their environment to a level unmatched in artificial systems. (I study vision and I see this sort of stuff all the time)
At any rate, the analogy to biological systems sort of works and sort of does not. Biological systems are not planned, rather they evolve (valid arguments accepted for religion. However, in human experience, biological systems evolve as we do very little in the way of planning outcomes unless one is making transgenics or cross breeding. Even then we are often simply along for the ride). Software too evolves, but well designed software is thought out and planned in advance with lots of end user input, subject matter expert input, and testing of code and interface to meet the users needs. In my experience with others code and commercial products, most software goes right into the writing phase with very little forethought or planning. "We'll get to that later" is the phrase I have heard again and again. The programmers that stay and get rewarded are the ones that can plan, work with subject matter experts, and listen and implement ideas and suggestions successfully. The ones that will not work long for me are the Prima-donnas that try and force their code down everyone elses throat saying nothing else will work. The reality is that either they are too lazy, or not talented enough and are unwilling to work hard enough to become excellent programmers.
I am seeing this more and more with the Microsoft way of writing code which is timeline driven rather than product driven. While being good enough for many, in reality it is third rate stuff without a commitment to excellence.
Visit Jonesblog and say hello.
That's about the most naive blanket statement I've ever read. "its always best to have good code, not code that looks good."
Consider a project that lasts 5+ years. Over the life of the project, there will be dozens of developers added and cut from the payroll. Assume your "good code" gets executed once or twice a week and instead of taking 2sec it takes 1sec. You've saved 1sec (possibly 2sec) per week which adds up to 52secs (or 104secs) per year.
Let's compare that to the human maintainer. Assume one person has to look at that code 1 time every 6 months and it takes them 30 minutes to understand it. That's 60 minutes that someone is getting paid to understand that code.
If the person earns $80,000 US, that's about $4 (assuming 4 week vacation) that was spent on the human. It's actually less when you consider that a person's salary is not their labor rate. Over the life of the project (5 years) you've spent $83 on your "enhancement".
Now, if the cost of up'ing the Mhz on your CPU is greater than $83 then it may make sense to implement the "enhancement". However, when you consider the price differential between a 900mhz processor vs a 933mhz processor (the argument being that a 933mhz processor could run the slow code and keep up with the 900mhz processor running the fast code) you won't find an $83 difference. It'll be more like $20.
That being the case, humans are more expensive than computer CPUs these days. Maybe they weren't in the past, but they are today.
Another argument for clean easily-readable and understandable code is that, if you take your argument, the entire system will become "enhanced" and no one will understand how it works. That will add on an additional overhead in the form of lack-of-enthusiasm for a project and will have financial implications.
All in all, I've worked on XP projects where code formatting and understanding was important. And I've worked on government contracts where people hack'ed their way through to save a couple of cycles. Maintainability speaks volumes... And I'd go with readability and understandability in a heartbeat...