Sacrificing Quality Costs More Than You Think

My last post highlighted my concerns with the use of the “technical debt” metaphor, ending with this question and summary:

Should quality be compromised?  When?

…the metaphor of technical debt seems to open the issue of quality as being a gray area, something that can be “traded away”.  The decision to compromise quality should not be made lightly under any circumstances.

I realize this statement doesn’t exactly blow your mind.  Of course, quality is important.  We all believe so.

So, let’s discuss a seemingly innocent scenario we may face as a development team:

In this iteration, we need to release our software slightly earlier than anticipated.  We won’t have the time to do the usual refactoring cycle after development.

Doesn’t seem like such a big deal.  And, on paper, it’s not.

However, what message did we just send to our developers?

In Peopleware (a must read), Tom DeMarco has this to say:

“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.”

Many managers and team leaders may think such a reaction to a relatively small decision is inappropriate.  They would be right.  However, as humans, we seem to be programmed this way.

To understand better, consider the Broken Window Theory, which provides further examples and research outside of software development:

“Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.”

As humans, we have subconscious feelings about quality of things around us, and we treat those things accordingly.  If we have a beautiful new car, flawless and free of scratches, we keep it clean and polish it regularly.  The first ding hurts the most.  Over time, we get more scratches, they hurt less, we worry less, clean the car less, and care less.

Looking back to our example, the decision to fast-track the release by a few days was probably not worth the harm to our team’s morale and self esteem.  The impact is largely subconscious, but very real, and does the most damage.

As creators and builders, we developers are driven by the desire to produce something which makes us proud.  When robbed of this feeling, for whatever reason, it hurts more than we may even want to recognize.