Use product bugs to highlight system breakdowns

When I say bugs, I don’t mean the living creatures as the image above suggest. Nor am I talking about bugs from a technical software perspective such as logic, performance, etc. It’s from a product perspective — bugs being pieces of code that do not produce their intended feature result.

Who should care?

Regardless of who decides where each bug is prioritized, we should all care about them. If you let bugs build up, the cost will compound exponentially as time passes. The software will become difficult to scale and the pace of features improvements will slow down.

In addition, from a product perspective, bugs and non-feature related work inevitably take attention away from the same pool of people who would otherwise be working on roadmap features. Thus, it is just as important to maintain a well managed bug backlog as it is to groom a feature backlog.

Health of bug backlog = health of system

In order to maintain a small bug backlog, it takes more than just prioritizing the work to fix the bugs. It also means maintaining a healthy system of how the work is being done.

Each type of bug reflects a different breakdown in the system. Thus, along with fixing each bug, we should aim to mend the breakdowns in how the work was done in order to decrease the likelihood of bugs appearing in the first place.

Regression Bugs = breakdown in testing system

Regression bugs appear when a new piece of code removes previous functionality. Especially when teams are moving fast, different groups can step on each other’s toes and override existing features.

Nevertheless, when a new function is completed, it is unrealistic to manually check all other functions to ensure no regression happened. This is where automated testing comes in.

If the right unit and functional tests are in place, they should be able to catch regression bugs as each new feature is built. Hence, if there is a regression bug, it also points to a breakdown in the testing infrastructure. Therefore, beyond returning the product to its original functionality when regression occurs, tests should be mended or added in order to prevent similar regressions in the future.

It is only by building and mending an automated testing infrastructure over time that regression bugs will become a rare occurrence and the team can operate as efficiently as possible focusing on adding new value.

Feature Bugs = breakdown in ticket structure

Feature bugs are when a particular feature doesn’t behave as expected when it was first created and subsequent tickets are needed in order to bring it to its intended behavior.

This type of bug points to a breakdown in how the tickets are structured. Sometimes when a single feature is broken down into small component tickets that cannot be shipped standalone, it is difficult to confirm whether it behaves in its intended way until more tickets are completed down the line. By the time you have a standalone function to test through the UI and discover it is not working as intended, the team might already be 3 or 4 tickets deep in implementation.

Nevertheless, I am not advocating for huge tickets. It is truly an art and skill to break down large features into shippable components that can be tested along the way. In addition, each component ticket should provide context on how it fits into the bigger picture so that in case the ticket writer missed explicitly spelling out an acceptance criteria, the team can bring it up and proactively account for it.

By forming a working system in which features are broken down into well written shippable components, feature bugs and communication breakdowns will decrease.

Refactors = breakdown in planning

Refactoring is the rewriting of code in a better way to perform the same functions as before. Often, it is unavoidable when you are building a product because no one can anticipate all the features/use cases in advance. Thus, it is not a bug.

Nevertheless, if it is needed immediately after a feature is introduced, it is inefficiency in the system that we should try to mitigate. When immediate refactoring is needed, it indicates a breakdown in upfront planning. Below are a few ideas to reduce this immediate need for rework:

• Uncover as many constraints to design as possible upfront
• Understand supported use cases and explicitly call out those that are not supported during planning phase
• Control scope creep and changes made during implementation
• Build enough time buffer in the schedule so there is less pressure to cut corners

Conclusion

Don’t let the bugs just bug you.

By using bug counts and refactor needs as a measurement of organizational system healthy, there is a path to improve the efficiency in planning, executing, and maintaining a scalable codebase that leads to a scalable organization.