Snaring Black Widows in Ladybug Clothing


The mood in the meeting was grim. All eyes were trained on Doris, the head of customer support. Doris surveyed the room as she spoke..."We have a problem in the field with the new release. Sixty-three users reported unrecoverable errors this week—a record high. An additional 152 people reported crashes, but the software recovered after reboot. This morning, I talked to an irate user who said he'd uninstalled our software after it crashed on him five times in a row. He wanted us to give him a full refund plus expenses. In short, the users are really angry. What do I tell them? When will we have a fix?"


"What the heck is going on out there?" the CEO snapped.

The VP of Engineering clenched his jaw. "I'll get right on it," he replied.

This scene has been replayed in software development organizations since the dawn of the information age. How does bug-infested software escape into the real world, causing users and technical support representatives such grief?

A common response is to blame the Test group: "How did you guys not find this bug?" This blaming stance puts testers on the defensive: "Maybe it's because the programmers gave us rotten code, management dictated the ship date, and no one listened to what we told them about the quality of the software!"

Let's suspend the attacking and defending for a moment and look at how bad software escapes. If there's a critical bug in released software, one of two things happened:

  1. No one found the bug before release.
  2. Someone found the bug but no one fixed it before release.

None of us likes it when bugs in the first category bite us, but it's the bugs in the second category that hurt the most.

Consider the history behind Doris's report. The testers reported that the software under test occasionally crashed for no apparent reason. The problem occurred very rarely, once or twice a week during peak testing times. The testers could not determine the circumstances under which the crash would occur. The programmers looked at the problem and couldn't figure it out either. The project team reluctantly deferred the issue to make the ship date.

Within a month after release, Doris was completely fed up with handling complaints from irate users and took her concerns to the executive staff.

Predictably, Doris's report spurred a great deal of finger pointing. The testers, who reported the problem, blamed the programmers for not investigating it thoroughly enough. The programmers blamed the testers for not being able to reproduce the problem in the lab. Everyone blamed Management for absurd schedules. None of the blaming led to better software. In fact, the blaming led to worse communication and schedule slips as team members scrambled to cover their backsides.

It doesn't have to be that way.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.