Speed Kills

From Programmer 97-things

Revision as of 09:40, 3 December 2009 by Kevlin (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

You are a programmer. That means you are under tremendous pressure to go fast. There are deadlines to meet. There are bugs to fix before the big demo. There are production schedules to keep. And your job depends on how fast you go and how reliably you keep your schedules. And that means you have to cut corners, compromise, and be quick and dirty.


You heard me. Baloney! There's no such thing as quick and dirty in software. Dirty means slow. Dirty means death.

Bad code slows everyone down. You've felt it. I've felt it. We've all been slowed down by bad code. We've all been slowed down by the bad code we wrote a month ago, two weeks ago, even yesterday. There is one sure thing in software. If you write bad code, you are going to go slow. If the code is bad enough, you may just grind to a halt.

The only way to go fast is to go well.

This is just basic good sense. I could quote maxim after maxim. Anything worth doing is worth doing well. A place for everything and everything in its place. Slow and steady wins the race. And so on, and so forth. Centuries of wisdom tell us that rushing is a bad idea. And yet when that deadline looms....

Frankly, the ability to be deliberate is the mark of a professional. Professionals do not rush. Professionals understand the value of cleanliness and discipline. Professionals do not write bad code — ever.

Team after team has succumbed to the lure of rushing through their code. Team after team has booked long hours of overtime in an attempt to get to market. And team after team has destroyed its projects in the attempt. Teams that start out moving quickly and working miracles often slow down to a near crawl within a few months. Their code has become so tangled, so twisted, and so interdependent, that nobody can make a change without breaking eight other modules. Nobody can touch a module without having to touch twenty others. And every change introduces new unforeseen side-effects and bugs. Estimates stretch from days to weeks to months. The team slows to a grinding plod. Managers are frantic and developers start looking for new jobs.

And what can managers do about it? They can scream and yell about going faster. They can make the deadlines loom even closer. They can browbeat and cajole. But in the end, nothing works except hiring more programmers. And even that doesn't work for long, because the new guys simply add even more mess on top of the old mess. In a short time the team has slowed again, continuing its inexorable march towards the asymptote of zero productivity.

And whose fault is this disaster? The programmers. You. Me. We rushed. We made messes. We did not stay clean. We did not act professionally.

If you want to be a professional, if you want to be a craftsman, then you must not rush. You must keep your code clean. So clean it barely needs comments.

by Uncle Bob

This work is licensed under a Creative Commons Attribution 3

Personal tools