The Pragmatic Craftsman :: Simplicity from complexity ::

Uncle Bob wrote an excellent post, Speed Kills. Is there a tradeoff between speed and quality, he asks.

If by “speed” you mean delivering working softwarequickly and repeatably release after release after release; thenmaintaining high quality is your only option.

I couldn’t agree more. In the long run, the only way you can move fast at high speed is if you have quality. Time and time again, I come across projects that were finished fast, with the thinking that they will never be modified again. (I’m not even sure if that’s always the case, but rather that quality was not a requirement.) After a few months, things change. They often do. And the project needs to be modified. What is your speed then?

It would actually make more sense to rewrite the project. But that’s almost impossible. Too many dependencies. Too much coupling. Who can read that and understand? Too risky. At that point, the easiest thing is to do is just add a special exception, an “if” statement that would make the thing work.

And the project quality degrades.

And the speed decreases.

Frustrating? You bet. Especially if you are not the original coder.

Wouldn’t it be easier if it was written with quality in mind in the first place?

Reference
Speed Kills by Uncle Bob