The Death Spiral

See if this scenario sounds familiar: There is a new software release in the works, and for some or all of the reasons we know so well—an overly optimistic schedule, scope creep, insufficient resources, too many defects found in test, you name it—it is running late. As the deadline approaches, pressure starts mounting to release on time. Maybe someone has a bonus riding on it, or there are potential penalties to be paid, or there is a compelling marketing event like an announcement scheduled at an industry conference.

Whatever the reason, the discussions eventually shift from whether to release to why not release? Arguments begin to emerge, such as:

"All software has bugs." The implication is that defects are normal and expected. I have actually heard people excuse high defect counts by pointing out that Windows was shipped with 50,000 known bugs. Whether this is true or not I can't say, but I find it amusing that it somehow seems to suggest that shipping buggy software is the hallmark of an industry leader.

"The longer we test, the more bugs we will find." It's as if testing causes bugs, or bugs don’t really exist until you find them. This is the kind of thinking that views QA as an obstacle. My favorite rejoinder is that if we didn't test at all, we wouldn't find any bugs and could release what we could claim was defect-free software. Voilá!

"We can fix these problems in the next release." In other words, let's just let the support and maintenance team deal with them. This is a favorite of organizations that separate new development from so-called maintenance, because it allows the original team to declare victory, claim the spoils, and let others clean up the mess. It also implies that the next release won’t have any requirements other than correcting the previous one.

"Users won't find these problems anyway." There's nothing like good old-fashioned denial. It's amazing how many people believe that testers spend all their time in the weeds, worrying about edge cases that no one cares about, so their defects are really just make-work so they will look good.

If the person making the decision is the one who will receive the bonus or be held accountable for the penalty or delay, then the odds are good that the product will be released as scheduled.

It's what happens next that I call the Death Spiral.

From Defect to Drama
Once the release goes out and users begin to encounter the known defects—and uncover those that were still undetected—the defects take on a completely different sense of urgency than they had when reported by QA, which may or may not be proportionate to the severity. This can range from annoying issues to outright crashes, and the immediacy of the required response is directly driven by the users' pain threshold. Because doing a proper analysis, development, and testing cycle may take longer than the users will tolerate, the response is delivered as a hot fix or patch that is rushed through development under battlefield conditions.

The problem, of course, is that shortcutting the proper process is likely to lead to unintended consequences. Thus, the fix for the original problem either misses the mark or causes other problems, sometimes more severe than the original one. This, in turn, raises the stakes, creating even more pressure to deliver a quick response, which in turn means yet another hot fix being rushed out . . . and so it goes, spiraling down and down.

You can usually tell which companies have previously experienced this phenomenon because they