Beautiful code…
O’reilly publishes Beautiful Code
Jonathan Edwards counters with a beautiful explanation.
Now, I haven’t read the new book, but I have a strong resonance with what Edwards wrote. You should definitely read the whole thing, but I few sentences jumped out at me.
A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious.
and
It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude.
Precisely.
If there’s anything that agile says, it says that we should build things simply and with a eye to revision because we not only are we “just not smart enough”, there are too many unknowns when we start.
The problem with “beautiful code” as a concept is that it is closely related to “beautiful design”, and I’ve mostly come to the conclusion that any design effort that takes more than, say, 30 minutes is a waste of time.
The concept also gets confused about what the goal of software is anyway. The goal is not to have beautiful, elegant, code. The goal is to have *useful* code that does what you need it to do.
Discuss and comment
PingBack from http://msdnrss.thecoderblogs.com/2007/08/14/beautiful-code/
Of course correctness needs to be #1 priority in a program, but hopefully #2 will be clarity.
With respects to over 30 minutes of design being a waste of time, I’m assuming you mean purely code-level design?
Doesn’t code have to be read by others and maintained by others?
In writing application code, I assume Darwin had it wrong. While writing a nice long expression may be elegant, I have to assume the 7th programmer (my target audience) working on the code will be a new hire, unfamiliar with the application, and possibly clueless. So, I’ll break the long expression down into something easily digestible.
Even then, it’s often not good enough!
Michael, if it we’re me I wouldn’t say code level design. I would say one work unit of design. Whatever that unit might be. For some it may be a 1000 ft. overview diagram, for others it may be a page, for still others it may be a function. I think that whatever one plans to do, accomplish or delegate before re-evaluating and moving on should take no more than 30 minutes of design time.
I suspect I can learn something from the book and will probably pick it up, but in the end, the code I write needs to work, be efficient and clear. I’m not overly concerned about writing so that the new hire can follow it; I’m concerned about writing it so that *I* can follow it 12 months from now when it needs to change and it isn’t fresh in my mind. The new hire will ask if s/he has questions. I’m certainly not going out of my way to obfuscate the code. Simplicity rocks – everything else is at first clever and later a pain.
I’m halfway through the book, and the thing I liked most about it isn’t that it has loads of techniques, or that it tries to tell you the "one true methodology", but that it makes you think. There was some code in there that I thought was horribly ugly – but I was always thinking about what might be more beautiful.
I think the title of the book is perhaps deliberately controversial – but the fact that we’re all talking about it says something. This isn’t a book that teaches – it’s a book you argue with.
(Personally, I’d put your 30-minute argument slightly differently – any design which takes more than 30 mins to EXPLAIN is probably a waste of time).
Stu
Isn’t it just a catchy title? The essays inside don’t have much to do with each other. "Boring designs" would not be so catchy.
You say "The goal is not to have beautiful, elegant, code. The goal is to have *useful* code that does what you need it to do."
I think this is too simplistic a view; they are not so easy to separate as concepts. Besides, if I was to concentrate on the latter without any attention to the former, I would probably feel compelled change careers in a matter of weeks. Constructing things that are "beautiful" [to us] is part of the joy of living day to day, no?
– Oisin
Great points… sometimes I have to remind myself that the architecture itself is not the deliverable! It’s always tempting to want to refactor some piece of old code because I want it to look better or be more "correct" from a design perspective, but many times that refactoring isn’t going to provide enough business value for all the time I spent on it.
I find that pair programming solves much of "not smart enough" problem. The common sense of one is always questionable. If two agree, success rates (and the chance of beautiful code) go way up.