Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Where Did All the Beautiful Code Go?
|
Posted: Mar 30, 2006 10:52 AM
|
|
My point was that there were not many bugs in that code, and it was a very successful project, but it was not beautiful code. It was ugly code that worked, was easy to maintain and develop, and did the job.
By contrast, I was later involved in projects that did aim at beautiful code, but failed because that code took too much effort to create and thus did not fit its purpose in a business environment.
The trick is to create beautiful code fast. Kind of like Mozart wrote music.
That works sometimes, but often it does not. In a business, there can't just be 2-3 developers, if you want grow that business. And when you have more developers, then it's like a city where you have Botticelli pieces sharing a street with graffiti. Yet, such cities do actually work. And some find beauty in graffiti, just as some find beauty in mind-blowing complexity.
Someone posted here earlier about MS widgets being spaghetti code. That reminds me of an article on Joel on Software on why one should not re-write one's software in a business environment. Old (and often ugly) code that's been around in production works, and has numerous bug-fixes, making it even uglier, but making it work possibly even better. What would be the business case for re-writing that code, if the code works 99% of the time, which is acceptable in the context of the user base? (And even a beautiful re-write might not result in significantly more reliable code.)
The business case would be to make developers happier, but that's not always a valid business case for shareholders. (And many developers, in a different context, happen to be shareholders, too, I suppose.) I have seen anecdotes about beautiful code resulting in increased shareholder value, but the evidence is so sketchy that I just don't see a causal relationship. I do see a relationship between code that works well and a business benefit (you can't really sell a product or service that does not work most of the time). But, as my earlier point was, "ugly" and patched code can work very well over time, much as ugly and patched city streets are capable of carrying traffic for centuries on. And maybe there is some beauty in <em>that</em>.
Yet, we need to remember that not all software is written in a business environment: there are academic environments, scientific environments, hobbyist environments, open-source environments, etc. It might be very appropriate in such environments to aim at beautiful code rather than "time-to-market," since the latter is not a concept.
And it is possible to create, say, an academic environment even inside a company, as many R&D departments have done. But then the purpose clearly must be kept in mind. For instance, if your research project becomes the basis of a product, and you move from the academic to the research environment, then the relationship to beautiful code must also change. We have to learn to freely move between these environments, just as a great musician can employ freedom and improvisation when playing jazz while adhering to exactitude in Beethoven.
> And if the code that you repeated "all over the place" had
> bugs, you just corrected it "all over the place", right?
> If that is your idea of an "easy to maintain" code base,
> all the progress in software engineering during the last
> 50 or so years has been lost on you. Sadly, you are not
> alone. In the Java project I am working on, I am
> struggling every day with code written by coders who don't
> understand what's wrong with repeating the same code more
> than twice.
|
|
Previous Topic
