During an email conversation last week, I suggested that my client change his naming of “bug” to “defect.” He asked why.
People don’t create bugs, but people create defects (or problems or faults). Bugs crawl in or fly in from the outside, when you’re not expecting them to. But we expect defects and problem in software. We can take actions (test-driven development, pairing, peer reviews, inspections, and more) to reduce the number of defects in our code, but those actions are very different than preventing bugs from flying into the house (putting on screens, closing doors). And, if we’re outside our houses, we can’t take similar actions to reduce the total bug population.
It’s possible that the last real bug was the first one, the moth caught in the hardware. Maybe there were more physical bugs that caused hardware to short out. But no longer. We rarely, if ever, have physical bugs to worry about.
But we have plenty of defects. I am convinced one of the reasons we have so many defects is that we call them bugs. When we call problems bugs, we avoid taking responsibility for the problems (defects or faults) that we have caused. The bugs didn’t just fly in and land on the hard drive. As the developers create the code, they also create the defects.
The first step in solving problems is to acknowledge that you have them. If you want to deal with the defect problem, stop calling those problems bugs. Bugs may be an acceptable name, but it’s not a helpful name. Call the problems defects or problems or faults — something that will help people realize they need to examine why it’s acceptable to allow defects into the code.
Call a spade a spade. And call those problems defects. They’re not bugs; they’re defects. Then maybe you can determine how to get rid of the ones you have and not make more.