Bug Reports Are Good

That’s right, bug reports are good. As long as they are good bug reports, of course.

This does not mean that bugs are good, though some can be fun. And quite a few are funny. But if we accept that serious tech is never to be regarded as “bug-free”, it follows that reports about bugs in the system are good because such reports should be able to help us track and trash bugs. This, in turn, leads to improvements in quality, adds to researchable product history, etc.

Bug reports are greeted and treated as though they are bad!

And yet, strangely, bug reports get a bad rap. It’s as if the reports themselves are somehow mistaken for the worst of the slimy, multi-legged, biting, stinging creepies about which they are written. Some developers take bug reports personally, as though a bug report filed against their code necessarily means they are being accused of something. And managers (including agency and other business owners) often interpret bug reports as indicators that their teams aren’t doing their work correctly, or that they have selected the wrong components for use in their projects.

Even worse, shot callers at many levels often find it hard to stick to otherwise well-proven tools and platforms upon the emergence of a new high-profile bug. And the higher the visibility of the bug in the community, the more panicked the response. Failing to recognize that bugs are part of life in software, on the web, and in tech in general, they fail further by not taking these reports in stride and simply addressing fixes and patches in the usual manner. Instead, they opt to leap from dependency to dependency in search of a “bug-free” alternative. Or they just burn time and other resources talking about how to respond to the newest bug. Sometimes, they’ll even complain about how their work is so negatively impacted by third parties that “don’t know how to do their jobs.”

Healthier views of bug reports see them as the inevitable result of complex labor in ever-shifting substrates and dependency sets. And if they are indeed inevitable (they are, really, at least for the foreseeable future), then we can make the choice to view these bug events as opportunities for continuous improvement (no matter how good the product is at any given time). So how do we get to these healthier perspectives? First, we need some background.

What is a bug report?

The term “bug report” is used somewhat differently in different contexts, but ultimately, a bug report is exactly what it sounds like: A report about a bug (a broken or missing behavior or the like). It can be a new report about a new bug, a new report about an old bug, an updated old report about a resurfacing bug, etc. When addressing this topic as generally as possible, I find it helpful to think of two types of bug reports: Formal and informal.

Formal bug reports are often entered into a Defect Tracking system, and they often follow a templated layout that is designed to ensure all critical data are included, as is an estimate of the priority and severity of the bug, and more. These bug reports are often filed by internal or partner staffers, and sometimes by other outside contributors (like fellow Devs in the community of an Open Source project on GitHub). Most folks who file formal bug reports are part of the component’s production process to one degree or another.

Informal bug reports often lack some of the detail we’d like to have when managing quality, as they are reported by users or automated systems that are not actually part of the production process of the component in question. These include submissions from our users, error notices from our hosts, etc. While these bug reports often require a little more investigation than the formal variety, they are also often enough for us to act immediately (such as the case with a notice by email from our web host, reporting that one of our WordPress plugins has been found to have a serious vulnerability which is best handled with an immediate update to that plugin).

What is a good bug report?

Good bug reports are clear. Action items, if any, are either stated explicitly or are easily understood from the nature of the error being reported. For example, errors generated by looping through an empty array can be addressed by checking array length before the looping begins. Or, we can “skip” to a different block of code if the code that was supposed to populate the array to begin with did not act as expected because of a failed query.

Some thoughts to keep in mind:

• Good bug reports make it clear what should be happening with the app instead of what’s actually happening.
• Good bug reports focus on the feature or behavior that is misbehaving, not on the Dev or the team or the company that produced the code that powers the ailing feature.
• Good bug reports can be referenced later when squashed bugs resurface (regressions and the like), and they can be updated and grown so that they become useful quality management instruments.
• Good bug reports include ice cream and beer rewards for whoever deals best with the bug being reported. OK, this isn’t actually part of the definition of a “good bug report”. But it certainly should be.

What is a bad bug report?

Bad bug reports fall short on one or more of the above. Simple enough, right?

How should Devs use good bug reports?

Good bug reports improve product quality, so Devs should welcome them and understand that they are not personal attacks.

Good bug reports also improve Dev skills, so, often enough, Devs should be thrilled with getting them. And all the new work required to resolve these bug reports should be viewed as an opportunity to sharpen Dev skills (and win even greater accolades for work well done, if that happens to be important to the affected Devs).

Good bug reports should be regarded as important work product that can save time, yield valuable statistics about product development and stability, and more. As such, they should be easy to find, easy to read, easy to amend, and always available when researching related workloads. Even incoming new opportunities that have important factors in common with the product about which these bug reports have been filed can benefit from a robust collection of well-managed bug reports.

How should management and ownership use good bug reports?

First, and perhaps foremost, management and ownership should understand how good bug reports should be used by Devs. Second, and almost as important, managers and owners need to accept the fact that bugs happen, so bug reports are good and should rarely if ever result in the maelstrom of emotional reactions that sometimes make every bug seem like a civilization-ender.

Relax, ask whether this is indeed the end of an era or “just another normal bug”, and move on.

All this implies and requires, of course, that management and ownership build bug-fixing time into the regular production and maintenance workflows. Because failing to plan for the occasional failure likely means that fighting failures will become an ever-increasing portion of our day.

How should everyone use bad bug reports?

Figure out quickly whether the bug report can transition from a low quality report to a more useful instrument, such as by requesting more information.

But until we have a “good” bug report, the threat of any new or resurfacing bug should never cost serious time and should certainly not inspire any shot callers to doubt the fundamentals and drive everyone around them crazy with exaggerated fears and costly responses.

Conclusion

Bug reports are good, even though bugs are rarely actually good news. If ever. Bug reports are useful instruments that can help us deepen product quality as well as our own skills.

Ultimately, it’s a question of company culture. If the team has a healthy and realistic view of tech, of quality, of the realities in which we build (and maintain!), bug reports will rarely spawn panic. But if strategic decisions are made by folks who have neither the knowledge nor the temperament to evaluate bugs realistically, any bug report can become a source of disproportionate mayhem.

Maybe, given these facts, questions about how bug reports are handled in our organizations are not simply about quality assurance or quality management as might appear to be the case at first glance. Perhaps, by examining company reactions to bug reports (even the very informal type), we can learn far bigger lessons about the basic fitness and quality of the organization as a whole.