Member-only story
It’s not a bug, it’s a feature… no really
When a bug really is a feature
Bugs, put simply, are errors or defects in a software system. If you work in tech, you’ve probably heard someone say the half-joke, half-truth line “it’s not a bug, it’s a feature”. Often this is used in jest or to justify not wanting to fix a particularly difficult bug.
We have a bug in our backlog that we were recently debating whether or not to fix as part of another piece of work. I uttered a sentence that one of my team turned into an inspirational poster-esq image:
“If a software bug lives long enough in the system, it becomes a feature”
Some bugs are really obvious to users — for example, if I enter some information and it doesn’t save, this is clearly an error in the system that needs to be fixed. Others bugs are, to the user, just how the system works. Users don’t know what your internal requirements were and may not even know that something is considered by the company internally to be a ‘bug’ — they’ll just think it’s how the system works. Perhaps they’ll even like the functionality and find it suits their needs and workflows well.
If you have this logged somewhere in your bug backlog, and it takes you a long time to get to it, to the user you aren’t fixing a bug but taking away functionality from them.
You can’t just fix this ‘bug’. You need to make sure you understand how many users are impacted, whether they think it is an error or if it’s their desired behaviour and how many would miss it or find the system less desirable if it worked another way. Then, if you still decide to take the feature away (or, to you, ‘fix the bug’) you may need to engage in a change management process to ensure users know the system will work in a different way.
This may seem obvious but if you don’t step back to consider your users, and instead just plough through your long bug backlog, you make have unintended consequences and actually remove functionality from your users.
How we manage features in ‘bugs clothing’
Before developers start fixing bugs we’ve implemented a process whereby they are first reviewed. The head of QA and the head of Product and UX (me) review the backlog and consider the impact on users. If the bugs may really be features we make sure it goes through the UX team in a lightweight discovery and research phase before making any ‘fixes’.
