25 Jan 2015. comments
When does a bug become a bug?
What is a bug?
Should we track bugs?
Is it possible to have no bugs?
Recently Robert ‘Uncle Bob’ Martin went to twitter to make a bold observation:
Think about what it means to use a bug tracking system. You have so many bugs you need an automated system to keep track of them.— Uncel Bob Martin (@unclebobmartin) December 14, 2014
The initial gut reaction for some is “Yeah, we should just write less bugs!” which is of course what he’s implying here. But is it that simple?
What’s implied when questioning the value of a bug tracking system is that if we would only just not create the bugs in the first place that we’d be able to dump the tracking software and have happier users. What that implies is that all these bugs are programmer slip-ups that could be prevented at the time of writing the software.
The above line of thinking ignores the reality of many bugs whose lives did not begin at code construction time but rather evolved into a bug based on humans discussing the software with each other. Was Feature X supposed to behave in that way? Was Feature Y supposed to only be available to users A and B? Do product and design agree on what Feature Z should do and is that how it was implemented?
There’s no way around it, you need to have human conversations. Questions like these are not solvable by well-tested software or software engineering rigor. So long as it is possible for humans to misunderstand each other there will be bugs filed based on expected behavior not matching what is implemented by engineers. The only way to solve questions like these are by having conversations with your users, your team, and your business. These conversations must also happen often and continuously because many times a feature is not well understood until it’s actually prototyped or built, and then these ‘bugs’ are filed. The sooner you have these conversations the shorter the lifetime of these sorts of bugs; but they will have a lifetime.
Maybe we’re splitting hairs here about the definition of a ‘bug’ but that’s not really important when you’re trying to debate what constitutes a ‘bug’ to your non-technical colleagues. The software isn’t doing what they expected and it’s your job to make the necessary adjustments.
Making a bold claim like ‘we shouldn’t have a bug tracker’ is also a bit arrogant if you think about it. Let’s assume for a moment that you are the best engineer in the world and use the best software development practices. You practice TDD, you work closely with your customer, you release early-and-often, the whole nine yards. I hate to break it to you but you’re not perfect. You’re still going to introduce bugs. Because you’re a human and humans make mistakes. Human’s misunderstand each other.
And if you agree that you’re not perfect and that it’s possible you won’t have 100% understanding with other humans, isn’t it responsible to track your mistakes? If for no other reason than for you and the reporter to not let the bugs slip through the cracks?
Uncle Bob is no dummy. He’s been around a lot longer than most of us in software. I fully expect that he’d agree with much of what I’ve written here because there’s more nuance than 140 characters on Twitter will allow for. We do write too many bugs and we could use more rigor, more testing, more professionalism. But it isn’t a zero-sum game and we can’t “win” the battle against bugs. Your job isn’t to write zero bugs but rather its to minimize the ones that are mistakes and manage the ones that stem from misunderstanding.