Entering the room we used for daily project status review, the test engineer and my good friend was beaming: he had nailed three more bugs. I was cringing, because my curve of bugs found had just been yanked away from its nice trajectory towards zero. But he was right to be happy: those bugs had just disappeared from future customers’ world. “Bugs are good!” he’d say to cheer me up. He loved the intellectual puzzle, it was a hunt, he and the bug, predator and prey. And the bug would sometimes taunt him for weeks, but eventually he’d conquer it, the harder the better.
What’s a bug?
“A software bug is an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.” Bugs can manifest themselves in a wide variety of subtle and not so subtle ways: from a slow computer to a crash or a freeze. The most insidious bugs produce incorrect results, which can ultimately lead to catastrophic outcomes, such as planes crashing. The explosion of the internet introduced a relatively new class of bugs, the “security holes”.
There are many ways to classify bugs, but the most important to their resolution is whether they are “solid”, meaning they occur every time under easily reproducible conditions, or “intermittent”. A solid bug that comes to the developer desk with a procedure to reproduce it can usually be fixed quickly. Intermittents are the bane of testers. They sometimes disappear for months between appearances, and when they do they often leave no tracks.
In computer lore, the term derives from an actual bug found dead among the hundreds of very hot electronic vacuum tubes in an early computer. That computer had apparently stopped functioning when the unlucky bug, attracted by the warmth of the tubes cabinet, got zapped, frying some electronic component in addition to itself. In those days “debugging” meant searching for real bugs and extracting them from the hardware.
Bugs are here to stay
Because of the complexity of modern software systems, bugs are an inescapable component of writing code. It is estimated that, on average, released code has 1-25 bugs per 1000 lines, though this figure varies widely depending on the type of software, the quality of the developer, and the effectiveness of the testing. Bugs are introduced in all stages of development: design errors, spec writing, misreading the spec, coding errors, bug fixing errors, 3rd party component errors (e.g. operating system).
In 2002, a study commissioned by the US Department of Commerce’ National Institute of Standards and Technology concluded that “software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually.” 
Once one agrees that bugs are a fact of developers’ life, and that they are intensely disliked by the end user, then it’s easy to concur that finding them before release is important. It’s less intuitive how much more expensive it is to finding them late in the software life cycle. If a bug is discovered after release, it will likely pop up at a customer site, producing maximum damage. The total cost of fixing a bug in the field is several times that of fixing it during development. Customer support and technical support are needed to help and placate the customer, and since the customer needs to get back up immediately, a temporary patch is typically needed in addition to the permanent fix that would have been made before release. Add to this lost reputation and lost business.
On the other hand, fixing a bug before release but late in the development process can cost several times more than fixing it early. This usually happens when inexperienced managers, in an effort to save money and/or time, ignore the General Principle of Software Quality: that it’s cheaper to build high-quality software than it is to build and fix low-quality software.