Don't Call Them Bugs
Bugs vs. Defects
I really don’t like the word ‘bug’ when describing a piece of (missing) functionality that doesn’t work correctly or has unintended consequences. I much prefer the more accurate word: defects. If you use ‘bugs’, you’re doing yourself, your projects, and your customers a disservice.
It’s a Mindset
The word ‘bug’ brings a cutesy picture of a ladybug or maybe a little grasshopper, or maybe an uglier thing like a house fly or cockroach. Get real and be professional: these are defects. Don’t trivialize your work and its consequences. Call it what it is. Imagine you buy a car or a house (here we go with the metaphors) – how would you feel if the driver’s door had a flaw whereby the handle or lever would open the trunk on each odd turn, and open the driver’s door on each even turn? What about a defect where your GPS took you to the wrong destination? How frustrating or expensive would it be, for you as the customer, to work around that? If your software doesn’t do what you intended/written, then you haven’t tested enough. Shipping that product is, by and large, up to you. If your product contains untested/unpredictable behaviour, that’s all on you!
Yes, it’s a nice story about Grace Hopper and the moth at Harvard. Of course, it’s an easy feel-better-about-yourself term that’s used. However, it becomes an uphill battle for those professionals who care about terminology when there are products called Bugzilla and FogBugz in the bug-tracking line of programs. I use both, and both are great at what they do. Of course, the term ‘bug’ is well engrained into our minds and language, and has even crept into the language of the non-programmer.
Personal Software Process
This reminds me of one of the textbooks at BCIT’s CST program. It’s the Personal Software Process by Watts S. Humphrey. Watts is incredibly focused on software quality. One distinct lesson I got from that particular course was the concept of constantly recording and measuring. Defects per 1000 lines of code (KLOC). The other theme, perhaps in the book, or with that particular instructor, was this idea of ‘defects’, and not ‘bugs’.
Own Your Defects
I’ve come to this conclusion for myself when thinking about flaws in software:
Don’t trivialize those flaws with your words, own them. Call them what they are – flaws and defects in your software