In my life, I’ve used two bug trackers – FogBugz, and Jira. (And maybe TFS, but that doesn’t count. Or shouldn’t.) FogBugz was by far my favourite, although I’ve now learnt that it’s called Manuscript. Maybe I’ll give it a go. Anyway.
Notice how at this point I’ve been unconsciously referring to “bugs” – I’ve even called out “bug trackers” above. That’s interesting in that the subject of this article is about how talking about bugs is, in and of itself, harmful.
Jira describes itself as an “issue and project tracking software”. Manuscript now calls itself “project management”. It’s clear that all the cool kids these days want to think of themselves as project management tools.
This makes sense to an extent as that the central day-to-day activity in project management is tracking work tasks. It makes less sense in that project management is a whole lot more than “tracking work tasks”, but let’s stay on topic. My issue here is why do we talk about “bugs”.
Jira has the following default issue types: bug, epic, improvement, new feature, story, task, sub-task, and technical task. All bug trackers do this – they categorise the bugs. Or issues. Or whatever they are.
I’m a great believer in the power of language in business – very subtle language changes can have a profound effect on how teams work. And I in particular have an issue with the word bug.
The North Star for any software development team has to be the customer – it’s really the only star in the sky, the only one worth going towards. Software delivered has to meet customer expectations, and bugs are only part of that process. In fact, the bigger issue is that of customer pain – what pain points are being hit by the software being in the state that it is. (“Pain points” here refer to the idea of pain used as part of the sales process.)
Indeed, the pain may not be anything to do with a bug. It might be that the pain is caused by not being to bring on board a major new client without a given feature being in the software. (And to go back to Jira, what is that – an “improvement”, a “new feature”?)
Is there a risk of artificially prioritising work items identified as “bugs” over other things? I’ve certainly seen teams take the eye of the ball and start prioritising things that are “broken” over and above what the customer wants them to be working on. It’s also easy to say to a customer whose whole system has just fallen over “don’t worry – it’s just a bug”, which is not the most empathetic response to matters.
“Bug” is simply an unhelpful term. It’s a lab term for developers to use in the lab. The customer doesn’t care about bugs – the customer just cares about when a solution to their problem will materialise. All a customer wants to hear is that you’ve understood their problem, a solution has been agreed, and someone has been able to put a cost and deliver date on that solution.
The solution here is not to stop calling bugs “bugs”, because bugs are bugs. Trying to rename bugs as “faults”, or “defects” is just fiddling around the edges. The issue (no pun) here is to stop categorising cases, issues, whatever in the way that we do. It’s not important – it’s all just work to be done, they are all “tasks”, regardless of their origin or nature.
Try banning the word bug, and refer to all work to be done as “tasks”. It’s a very powerful move.
Our evolving "Digital 247" Software Architecture Methodology helps us guide our technical leadership. We maintain it in two forms — a benchmark that you can fill out to get a feel as to where you are with regards to your peers and competitors, and a 7,000-word downloadable white paper that is free to download and is full of helpful information and advice.