Bug reviews are a necessary evil. Your application is out in the wild and, inevitably, bugs will be found. If you're busy working on other things, these bugs usually get stuffed in the bug tracking system for later review. At some point you will sit down with all the product stakeholders and decide what sort of priority to put on these bugs. Everyone needs to agree which bugs are going to get fixed and which are going to get deferred.
As a developer, this is generally "yet another meeting". We show up. We give our thoughts on the bugs. Is this one difficult to fix or can you fix it during the meeting (kidding)? We don't assign priorities ... that's generally the job of the product owners. The product owner might be a direct customer or it could be an abstracted customer like a product manager or the sales team (the Customer Proxy in Agile parlance). We just throw in our $0.02
Now the real show begins. Sales flips out because this bug or feature request is holding up revenue. Product management may veto a ranking because of a more strategic matter. Marketing will scream that the competitors can make a Square Circle and that our product needs one too. There are feats of strength, ruffling of plumage, bun fights and kiva sits until eventually the bug list is placed in an ordered fashion. Bugs are ranked in some Priority and Severity such as Blocker, Critical, Major, Minor or Trivial / number codes / whatever. If you're really lucky, some bugs will be removed from the list as being no longer relevant or already fixed.
Then it's our job. Development will do whatever sort of voodoo it needs to do to estimate, assign and work on these tasks. A new release is issued and the process repeats. Ideally the cycle time between bug review and product release is suitably short so that the bug rankings don't shift too much. No real magic here.
And, as we all know and every Agile pundit will evangelize, the priorities will shift.
If you get your priorities from Sales, your priorities will shift on a near-daily basis. The hottest customer will get the most attention. Depending on the length of your sales cycle, don't plan on taking on any ambitious new features or refactorings because you're likely to get pulled in a new direction tomorrow. One thing I like about having a good product manager to work with is they can temper the rapid mood swings of sales people and boil them down to a common theme or essence.
Regardless ... not all of the bugs can get fixed. You build up a bug backlog. After a while, in an attempt to keep the meeting short, you stop reviewing the Minor or Trivial bugs and just focus on Blockers and Criticals. After a longer period of time, you can't manage the duplicates anymore so the list grows even longer. It's a Broken Window. Because of the organizations inability to effectively manage these bugs the overall effect to the end-user is a rash of problems that are simply never addressed. Your application is dying and you can't prevent it.
Here's the real kicker: it may have nothing to do with the quality of the code or the process. Your code could be clean and readable, but simply because of market forces there is an unmanageable backlog. What can you do?!
It's a hard problem, but here are some suggestions I would make to help get you back on track:
Group your bugs and look for architectural commonality.
You may notice that large collections of bugs stem from a common architectural place in the code. It may not be obvious at first. In a separate worksheet, try and group your bugs by software sub-modules and look for alternative approaches that might kill many bugs in one swat. You may find that cutting off an arm will save the body.
Freeze all new feature development and do Bug Sprints
Push back on new feature requests or enhancements. Use all of your political powers to rally support about the importance of getting the bug list reduced. Try alternating Bug Sprints between normal iterations in an attempt to get the bug count down.
Remove functionality
This is often not as hard as it sounds. Is the bug related to a legacy feature? How many customers will be affected if that feature is no longer there? Can they live with a work-around? Removing lesser-used functionality means less code. Less code means happier developers.
Shore up your tests
Are you lacking some critical code coverage in your unit or functional tests? How many of these bugs could have been eliminated with better tests?
Hire a usability expert
Are the bugs related to confusing UI, complicated configuration steps or poor documentation? Could the product benefit from a usability review? Your product might be stable, but due to poor usability you are seeing a high number of bug reports?
Replace third-party components (or start using them)
Do your bugs stem from a flaky piece of third party code? Can you replace it? Alternatively, do your bugs come from a piece of code that was developed in-house but can now be replaced by an off-the-shelf alternative?
Start hiring or Split the Team
Perhaps your growing bug list is a symptom of not enough resources? Should your company make the investment in another developer to help share the load? If so, can you ensure that they won't be used by the Customer as a means of slamming even more functionality into the product? If not, consider splitting the team so that the Customer deals with one group just for new functionality and the other group just for bug triage and repair. Balance the size of the teams according to how dire your situation is.
And then ...
... fight tooth and nail to keep the bug count at zero. Always fix bugs first. You will get incredible pressure from sales to sweep them under the rug and some bugs can be notoriously difficult to find. Ask for help. Hire a highly skilled consultant to help you fix the bug if need be. But try to keep the bug count to zero or these Backlog Broken Windows may kill your productivity (if not your product).
Next time, I'll try to give some of my thoughts on how Kanban may or may not be able to help with this problem. Until then, I look forward to your thoughts.
3 comments:
Always run toward bugs, not away from them. This is especially critical in complex multitasking code.
A bug might disappear if you make a change, but you're not sure why. ALWAYS get to the bottom of anything which seems odd. Never be satisfied with a "fix" you don't understand.
The secret is, fix them immediately while you still have some idea what changes might have introduced them. If you do not, you will be facing bugs without the hint of changes which caused them.
I think one of the hardest things to do is dealing with features that would be nice but are pushed off into the future every time. Rigorous honesty would close them as "will never get around to this one" but that's a slap in the face to the department that requested the feature, so it drifts every onward.
~Matt
I think in a lot of cases, what is reported as a bug is actually a change in requirements for the application rather than a defect in the code. Whether it be part of the discovery process by the end user or a change in a dependency along the way.
Sure, there are the goofy things that come up because of implementation decisions, but I like what you said about grouping bugs and taking a step back to see if there is some kind of missing spoke in the wheel that addresses a whole bunch of issues at once.
More than once we have gotten rid of dozens of bugs by implementing a new (perhaps better) feature in place of a legacy 'idea' of what should happen in a system.
Post a Comment