Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Friday, June 09, 2006

Software Misconceptions Revisited

My last post on common misconceptions about managing bugs generated quite a few responses, so I thought a followup was in order.

Some thought that my contention that many believe that all bugs should be fixed was simply a "straw man" argument. In other words, I couldn't possibly believe that anyone really thinks that.

I guess that's the problem with generalizations, so I'll be more specific.

I've worked with quite a few people who DID think exactly that, and it affected many of the decisions at those companies, and not always for the better.

In particular, one QA manager routinely prevented software from shipping because the CTO had declared a "Zero-defect policy". This meant that in theory, we couldn't ship the new version until the defect tracking system had no open items.

As you might expect, each team spent the next few days tranferring bugs logged against their areas to other potentially responsible parties. Without telling them.

This also kicked off lots of heated arguments with the QA team as to what exactly constituted a defect. I can't prove it, but I think the entire QA team got free lunches for a week. This seemed to correlate with a new level of flexibility re: "bug " versus "enhancement."

Moral of that story: zero-defect policies usually just force bugs underground. Instead of having no known bugs, you wind up with no DOCUMENTED bugs that everyone knows about.

By contrast, another company I worked for was obsessed with features. There was no time to fix bugs, we had to get out the latest features NOW! The development team was very talented, and my some miracle we were able to keep delivering. The system quality did start to show signs of fraying, and the stability was somewhat less than rock-solid.

I've seen these patterns over and over again, both in companies I've worked in, and those that my friends and colleagues have. It's a form of corporate unconsciousness, where things get done, but no one really is sure how or why.

This isn't just a management problem though, I've seen unconscious behavior at the developer level also. Unplanned "tweaks" and "cleanups" of perfectly functioning code that caused major problems in production. An extra feature added in that no one asked for, which destabilizes the system or confuses users.

Anyway, that's enough on that for awhile, but I wanted to get you thinking about ways we can develop software more consciously. It's not just about fixing bugs or not fixing bugs.

It's about approaching development with the same care we approach a by-the-pound salad bar. Load up on the high-value, tasty items and leave the heavy, bad-tasting things where they lie.

For more on agile tools and techniques:
(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • Looking at the number of comments compared to the previous post, I assume you manage to please everybody !

    Indeed, few people have solid arguments to justify extreme positions such as fix every bug before shipping or just add features and do not care about bugs.
    I think the term "corporate unconsciousness" is the good one.
    Sometimes, a few people speak louder than everybody else and their recommendation become the standard.

    Anyway, when you know that a fix/not fix decision is more a shade of grey than a black or white decision, you're still not done. I wrote a followup on this topic at

    By Blogger Oaz, at 12:43 AM  

  • "This isn't just a management problem though, I've seen unconscious behavior at the developer level also. Unplanned "tweaks" and "cleanups" of perfectly functioning code that caused major problems in production."

    I must disagree this is a management problem, to many times have I seen a developer raises the issues that a particual code need to be cleans-up, the manager ignores the issue. Thus giving his silent okey for tweaking and clean up when ever.

    By Anonymous Anonymous, at 3:19 PM  

Post a Comment

<< Home