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.
Previous Topic
