Sacrificing Quality – Part II – Kaizen
September 15, 2009
Recap of Part I
In my last post, I described how sacrificing quality can adversely impact the morale of your development team. In that post, I cited a particular quotation from Tom DeMarco in Peopleware:
“We all tend to tie our self-esteem strongly to the quality of the product we produce… Any step that you take that may jeopardize the quality of the product is like to set the emotions of your staff directly against you…
…the decision to pressure people into delivering a product that doesn’t measure up to their own quality standards is almost always a mistake.”
The rest of that post described the psychological affects that compromising quality may have on a development team.
This post will highlight another problem that compromising quality can have on your development team – making it more difficult to attract (and keep) the best developers.
“We managers tend to think of quality as just another attribute of the product, something that may be supplied in varying degrees…
…The builders’ view of quality, on the other hand, is very different. Since their self-esteem is strongly tied to the product, they tend to impose quality standards of their own. The minimum that will satisfy them is more or less the best quality they have achieved in the past.”
In particular, notice the last sentence: “The minimum that will satisfy them is more or less the best quality they have achieved in the past.” This characteristic is one of the best traits we developers have – the desire to continuously improve. Kaizen, the process of continuous improvement, is increasingly attracting attention as a key factor in making huge long term gains, both for companies and individuals. It is also a key principle behind agile techniques such as Extreme Programming and Scrum.
In our industry, continuous improvement is not just a desire, but also a survival technique. Things change so quickly, if we do not improve continuously, we will not only fall behind, but become obsolete in a few short years.
With these thoughts in mind, now consider what happens when a developer is told to accept a lesser quality product. On the rare occasion, the developer might only be disappointed or annoyed. If it becomes a rule, rather than an exception, any good developer will realize this approach will lead them quickly down a dead-end path. And the more passionate your developer is about their career, the faster they will reach this conclusion.
Again, taking shortcuts on quality is likely to affect you more in the long run. Where you might be able to deliver things sooner in the short term, you are more likely to lose the developers that can deliver faster in the long run. Don’t risk losing your best people by not allowing them to do their best.