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.

About these ads

7 thoughts on “Sacrificing Quality Costs More Than You Think

  1. Pingback: Shortcomings of the Technical Debt Metaphor « Chris Melinn

  2. Pingback: chromatic (chromatic) 's status on Tuesday, 21-Jul-09 19:00:39 UTC - Identi.ca

  3. What about when our “need and want” for caring is removed for the sake of
    economy and (so called) project efficiency? This would be a contributing
    reason why many “off-shore” model projects fail. Having groups of
    geographically (and sometimes culturally) isolated people, building something
    that they are not emotionally (or at least mentally) invested in (through no
    fault of their own), cannot possibly lead to producing a quality software
    product.

    • @Tommy:

      I understand that many software organizations attempt to reduce cost and improve efficiency by relaxing their standards for quality. In fact, my intention was to highlight some of the fallacies of this approach.

      Instilling a sense of pride and quality should start from the top and trickle down to all layers of an organization. If an organization (or manager) feels compelled to apply pressure towards “efficiency”, developers will actually become less productive, especially in the long run. “Forcing” developers to sacrifice quality for efficiency will quickly remove their sense of pride and ownership in what they are trying to create.

      I also agree that larger and more distributed organizations face additional difficulty in sending a consistent message. However, this can still be achieved if the organization is truly committed to their message.

  4. Pingback: Sacrificing Quality – Part II – Kaizen « Chris Melinn

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s