What’s So Wrong With Quick and Dirty Code?
The twittersphere and blogosphere have been burning up (at least in my corner of the social graph) with the topic of clean code vs expediency. In essence, the question seems to be, “couldn’t we deliver software faster by not worrying too much about clean code?”
I think not. Consider these trivial examples from domains with which we are (mostly) all familiar:
- Could we not save a minute or so by not tying our shoes in the morning?
- Isn’t the kitchen more efficient if we never bother washing the dishes?
- Who has time for car maintenance? Isn’t it faster if we just proceed to work riding on bare rims, with black smoke belching forth from under the hood?
These questions suggest obvious misperceptions, ones which functioning adults in the modern age easily recognize as dangerous. But each of us had to learn avoid them at some point. And there are human beings (called children) for which the attendant dangers may not be so apparent.
The basic value proposition in QuickAndDirtyCode™ that I’m hearing is that it’s faster. But it’s important to recognize that the risk in each of these mis-perceptions isn’t merely of the moderate, inverse-linear kind. If I’m an idiot and think I don’t need to tie my shoes when I go out, the danger to me is not merely that it will actually take longer than if I had tied them. The danger is far worse: I could stumble on the stairs, injure myself, and impair my ability to go out for a long time.
The risk in using unwashed dishes and utensils in the kitchen isn’t simply that it actually takes longer to cook with them. In point of fact it might be faster in some situations. But there exists the very real risk of laying the entire family low with food poisoning, which is a major slowdown to many people, not just one.
And if you drive your car on the rims, you’ll be walking soon, if you’re lucky. In the meantime, you’ll lose time, equipment and maybe worse.
The idea that quick, dirty and “expedient” coding edges past clean code in the short term is a terrifically naive one. Software projects (and their several parts) tend to grow when they are successful. That’s just what they do. As the codebase grows, the risk in not writing clean code isn’t merely that it ultimately may take a bit longer; dirty code can sink a project. Dirty code eventually dooms projects to one of two outcomes: a complete re-write, or total failure in the form of abandonment of the project’s goals. Clean code helps us steer clear of these two outcomes by offering us the chance to build better software on top of what we’ve built in the past.
So what do you do if you’re new to software development, and clean code doesn’t come naturally? It seems clear to me that until we know enough to take the time to tie our shoes, we are not ready for the Big Time. If we won’t wash the dishes, we shan’t do much cooking. If we won’t get the car fixed, we won’t drive very far. And if we don’t learn to write clean code, we won’t be delivering much working software. For the less experienced developer, there really is no viable alternative: learn to write cleaner code.
