Today, I would like to share with you how developers fix bugs. If you are a developer yourself, this story may sound familiar, but if you are a more high level project manager or project owner, developers will have a tendency to hide the issues for as long as possible, so if you are one of those, you may not even know that these kinds of bugs actually exist.
It’s not really because developers don’t want to discuss the issues, developers are usually very happy to share annoying bugs with anyone that would listen. But many project managers and project owners don’t want to see bugs, they want to see “working software”, so developers hide whatever is not working from their eyes for as long as possible.
Scenario
In this scenario, there is a button, and the button is blue.
One customer uses the keyboard to navigate the user interface, and when that customer tabs on the button, the button appears pink. Let’s call that customer “Customer K”.
Another customer uses the mouse to navigate the user interface, and when that customer hovers the mouse on the button, the button appears red. Lets call that customer “Customer M”.
And yes, for the purpose of this scenario, the users think that the correct color for the button is the color that appears when they interact with the button. For both of the customers, the color blue is not the correct color.
Bug #1
Customer K tabs on the button and see that the color is pink. Customer K files a bug:
Button is blue, but becomes pink when tabbing on it with the keyboard.
This is inconsistent.
The button should be a different shade of pink.A developer comes, spends an hour finding a suitable shade of pink, and reports the bug as fixed.
Bug #2
Customer M hovers the mouse on the button and see that the color is red. Customer M files a bug:
Button is pink, but becomes red when hovering the mouse on it.
This is inconsistent.
The button should be a different shade of red.A developer comes, spends an hour finding a suitable shade of red, and reports the bug as fixed.
Bug #3
Customer K tabs on the button and see that the color is red. Customer K files another bug:
Button is red, but becomes pink when tabbing the keyboard on it.
This is inconsistent.
The button should be a different shade of pink.
By the way, you already had fixed it in Bug#1, why did you break it again?Please keep in mind that the three bugs may be reported in the span of several months or years, and that different developers may handle the fixes for different bugs, and the customer will probably not include a nice reference to the previous bug.
So at this point, a developer comes, and the conversation in his head goes as follows:
— Something is definitely wrong there.
— Should I tell my PM/PO?
— No… it would take two hours just explaining the situation and he probably doesn’t care
— Let’s find a suitable shade of pink, what did the other developer use? I probably can find it in the file’s history.
— And I’ll keep that nice shade of red as a comment for when Customer M files his next bug.
— And if I can find a way to distinguish which customer is which, I can send to each customer the color he wants and everybody will be happy
And this is how to go from unmaintainable code to even more unmaintainable code.
Conclusion
The particular color problems in the story above may seem quite insignificant, but many times, similar situations occur and should really require a functional decision from the PM/PO, which should arbitrate between
- Defining which customer is wrong, and which customer is right, and in this particular case, every customer is right because the color scheme is inconsistent, but every customer is wrong because the button should probably display different shades of blue
- Implementing a configuration setting to exhibit for each customer a customized experience. This should be done wisely, because every additional configuration adds complexity to the software and makes testing more difficult by increasing, often exponentially, the number of possible scenarios.
What can you do as a PM/PO ?
A simple first step would be to let your developers talk to you about the existing bugs, and take them seriously. Only features should be demoed to customers, but bugs should be demoed internally, or at least discussed, to make sure that customers never see them.
Bugs are not just things that arrive in your mailbox one morning and are supposed to be dispatched and gone as soon as possible, but a sign that improvements are necessary. And sometimes the first improvement is better communication from developer to PM/PO.