Nik Silver tells the truth about quick and dirty development. I was particularly interested in a couple of the points he makes:
If you’re my customer and I’m your techie, then there’s a significant and unfortunate thing about quick and dirty that I need to tell you: You get the quick, but I get stuck with the dirty. Or to put it another way: the cost and the benefit are not felt by the same person.
That’s not strictly true of course. The customer also bears some of the cost of quick and dirty development. Particularly when the next feature takes twice as long to implement because of the dodgy foundations that it’s building on. But it’s generally true that the developers bear far more of the brunt than the customer.
Quick lasts only a short time, but dirty lasts forever.
More precisely, the benefit of quick lasts from the time the quick thing is released to the time the “proper” thing would have been released; and the cost of dirty also lasts from the time the quick thing is released, but it goes on until the time the software is rewritten or deleted.
Oh, that’s certainly true. There’s a particular kind of depression that falls on a development team when they realise that their quick and dirty solution will be the bane of their lives for far longer than it would have taken to do it right in the first place. I’ve been on teams where the cost of a quick and dirty solution is still being felt years later.
Far better, of course, to be quick and clean. But the difference between clean and dirty is often hard to see at the start of a project. That’s where good unit tests and constant refactoring come in.