The Quality Reduced Product

I revisited the concept of the quality reduced product today when a product manager insisted that the software development team take a really low cost option.  I reminded the product manager that the typical steps in delivering a product in less time and for less money result in lower quality.  Whilst the product's end user willingly consented to this trade off, my warnings regarding the impact on the team were largely ignored.

The heading of this post is taken from the seminal book for Software Managers, Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister.  In the chapter Teamicide they list the sure-fire ways to inhibit the formation of teams and disrupt project sociology.  Quality reduction of a product is one cause.

... [quality] concessions are extremely painful to developers as their self-esteem and enjoyment are undermined by the necessity of building a product of clearly lower quality than they are capable of.  An early casualty of quality reduction is whatever team identification the group has been able to build.

This is also discussed in Rob's post Nine Things Developers Want More Than Money, he reminds managers that being setup to succeed is key to developer motivation. 

Developers want to build software that not only works, but is maintainable; something they can take pride in. This is not in-line with product development’s goals, which are for developers to build software that works, and nothing more.

The first thing to go when time is tight is quality and maintainability. Being forced to build crap is one of the worst things you can do to a craftsman. Delivering a project on-time but knowing it’s a piece of crap feels a heck of a lot like failure to someone who takes pride in what they build.

In conclusion, whilst the effects of quality reduction are intangible in the short term, the long term effect on a team's engagement and motivation can be catastrophic.