June 17, 2008, 9:50 PM — Some time ago, I wrote about how economics and human psychology often conspire to make the results of large engineering projects, um, less than perfect. I even got a mention in a dictionary entry about cruft. Yay!
Whatever the end point of a design is, we tend to be able to stand back and say "you know, it would have been better/faster/cheaper to build it this way instead of that way...".
More often than not, when we look back at design decisions that resulted in inelegant/ineffecient products, we find that that economics and human factors are the root cause - not engineering errors. Sometimes crufty "hacks" in a design can be traced to design mistakes but often, the engineers have it under control. They just have to live with the fact that money and people and politics and all that stuff invariably influence design decisions.
What looks like an avoidable crufty hack with the benefit of hindsight, may well have been an inevitable consequence of circumstances.
Recently, I have been pondering the mantras of agile development methods and the "do the smallest thing that can possibly work" mantra in particular. Do something small but useful. Then do something else small but useful. Now stand back, look at the work and refactor so that the second bit of useful stuff does not look like a bolt-on to the first bit of useful stuff. Keep the design "clean" by constantly re-factoring as you add useful stuff.
I love it.
It beautifully captures how building stuff in the world of bits is very different from re-building in the world of atoms. In the real world, if you build a little, then a little bit more, you end up with a mess because you do not have the luxury of blowing it all up and re-arranging everything. But in the bit-world, you can always completely re-arrange stuff to avoid the mess. Or can you?...
No, not always.
Let's imagine you build something useful. In the software world what that generally means is that you have built something that can inter-operate with other useful things. With that concept of inter-operation comes a re-factoring snag. In order to inter-operate you need APIs/Data Formats/Protocols etc.
These form a "contract" between you and your users. Sometimes, a complete re-factoring of a software project can happen without impacting the contract but often it cannot. If you break the contract, you have a problem. Contracts like this are the software equivalent of concrete. You cannot just blow them up and start again when you feel like it. That is the bad news.
Now for the good news. If you have a contract problem that means you have built something useful. The alternative is a cruft-free design but with no users. Now which would you prefer? The crufty one with the user base or the perfect one with no users?
Enjoy the cruft. You have earned it.
