There’s a lot of confusion about how to classify software issues. Is something a programmer error, or is it a design defect? Is a misbehaviour a failure or is it an unsupported situation? This sounds like a game of “pass the blame”, and it’s avoiding the key goal: getting issues prioritized and mitigating risk.
That’s Not A Defect
An expression that really bothers me is “that’s not a defect, it’s supposed to work that way.” It’s an all too common response to a complaint about a product (software or otherwise). I have no idea how this is supposed to make the user any happier.
The user has a problem with the product. It doesn’t matter to them if the programmer has implemented it according to spec, and the spec is wrong, or whether the spec is right and the programmer got it wrong. Either way it isn’t doing what they want.
Chair Keyboard Interface Problems
Claiming something is “user error” is another disingenuous way to avoid the problem. When a user comes to us with a problem, they are looking for a solution. We can’t simply say they are doing it wrong and send them on their way.
Maybe the user needs to be taught how to use the product. This could involve better documentation, online tutorials, or specialized training. Or maybe the product needs to be made more accommodating. It’s often easier to change a product than try to re-educate users.
You shouldn’t be using it that way.
Using products for something other than their intended purpose is common. A user has a real need, and chooses a product that seems like it’ll work. A support request comes in and it leaves the product managers and developers baffled. Why on earth is this user trying to do this?
Don’t just label an issue as “unintended use” and move on. These are to be fixed just like any other problem. We have the choice to either support that use-case, or find out why the user thought it was supported. Perhaps the “defect” is a miscommunication with the marketing team about the target audience.
Focus on Priority
Any time the experience of a user doesn’t match with their expectations, we have an issue. And I really like the word “issue”, since it’s non-committal about the root cause or intended solution. It gives us a large bucket to consider all user feedback equally.
Instead of lingering on how failure analysis defines the failure modes, let’s focus on the prioritization aspect. Every issue ultimately has an associated risk level. What is the potential loss if we don’t address this issue? Or to think positively, what is the potential gain if we do address this issue?
Once we have a rough assessment of the value, we can start looking at options.
Look for who can fix it
In a complex system, there are always several approaches to resolve an issue. Firstly, we rarely need to, nor can we, fully resolve an issue. The best we can do is mitigate it, or to think positively again, partially exploit it. Secondly, while it is helpful to know the potential root causes, we don’t always need to address them directly.
It’s important to look across the whole organization to find the options. Perhaps something was a mistake by a programmer, but perhaps a simple change in the documentation can resolve the issue. Maybe sales sold it to the wrong people, but adding a new feature to accommodate them isn’t so hard.
This is another reason why perfectionism is bad in programming. How the user perceives the product is very different than a programmer.
Trying to find the perfect label for things that are defects, versus bugs, versus failures, doesn’t get me further in finding the solution. Often I find excessive labelling does the opposite, as the team starts to interpret these labels as priority, rather than making an honest assessment of the risk.
If in doubt, just use the word “issue”.
