Don't compromise quality for speed

Ron Jeffries has just blogged about dropping quality in favour of speed. Take a look at Quality-Speed Tradeoff — You’re kidding yourself. Having seen many, many projects fail because of this common fallacy, it is a subject close to my heart (but there goes the draft blog article I was writing....).

In summary, there are two choices. Subjective historical addenda are mine based on my experience:

• Reduce quality to go faster. You might get ahead short term, and you might even get ahead longer term if you don't add too many bugs and if you don't make the code uninhabitable. [But history is really not on your side here.]

• Increase quality to go faster. There is a chance that you will over-polish and not add important business functionality. [Historically this will not happen. Especially if you make this possibility an integral part of the quality process by holding regular customer product reviews and focus on delivering important business value first.]