Pride & Bug Reports

Bystander effect

In my experience, software bugs are often affected by a virtual bystander effect, or more accurately, a diffusion of responsibility. The internet feels vast and infinite, there’s always someone out there with the same problem you’re having. With a belief that so many other people are running into this issue, someone else is bound to have reported it, right? And we then land with, in the immortal words of Homer Simpson, “Can’t someone else do it?”

Very few people like writing bug reports. If it’s already been reported, that makes it so much easier. You can just downgrade and wait until it’s been fixed. The problem happens though, when everyone assumes it’s already been reported. This can lead to countless posts online alluding to an issue, with no one actually having written out a detailed description of it. The more of those posts that people see, the worse the issue becomes.

It’s also not uncommon with software, to need more information after an initial report. Not all bugs are super straightforward and narrowing it down based on common areas between multiple people’s reports can sometimes actually be required to fix something. Just because one person has already reported an issue, it doesn’t mean your input isn’t helpful. Oftentimes software projects will tag bug reports with something along the lines of “More information needed.” As the name implies, this means the bug cannot be resolved without more information. Sometimes that can be more information from the initial reporter, but oftentimes additional information from someone else experiencing the bug can be more helpful.

The developer experience

As a developer, naturally stumbling upon threads like that can be uncanny. There have been numerous times where I’ve seen a thread titled “WorldEdit isn’t working,” or something along those lines with any of the various open-source projects I work on. Seeing the original poster vaguely describing that something isn’t working, but not in enough detail to actually file a bug report myself. Seeing the replies all just agreeing the version is broken.

Usually, I don’t like to pop up in spaces like that. I don’t like looking for, or replying to, active discussions about my software on the internet. When I see posts like that, however, it’s hard not to. I’ll write out a little message acknowledging the report and asking for some additional information to help me track down the bug. Unless I’m the first reply though, it rarely actually amounts to anything. Everyone assumes the original poster contacted me privately and provided information, and the original poster has likely just done what others suggested and moved on.

Like many developers, I care about my software. I don’t want people to have a bad experience with it. To see people claiming there are a bunch of reports for an issue I’d never seen before can be demoralising. To have someone come to support and ask, “Why isn’t the issue with the latest release fixed yet?” only to say they don’t have time when they’re asked to properly explain or report the issue we’d never heard about before.

Contrary to popular belief, most software is actually tested before it goes live. Usually, the bugs that make it through to a release only happen if you take specific steps or are running it under certain conditions. Without knowing what’s broken, and what conditions it’s broken under, we’re likely to never know about it. If we never know about it, issues continue to go unfixed, and systems relying on stable software begin to suffer.

Testing makes the world go ‘round

As a user of software, one of my favourite things to do is beta test. I am one of those weird people who love to submit bug reports. Beta testing does, however, feel like it’s slowly become an exclusive club for risk takers to get new features earlier. It’s no longer actually associated with testing. Testing is the entire point though; betas are created to try and catch bugs early before a full release is cut.

When browsing discussions around the beta releases of various pieces of software, it’s common to see people mentioning the various things that are broken. Either complaining about how it breaks their workflow, or warning others to not upgrade if it’ll affect them. I often wonder, how many of those commentors reported it via the proper channels?

It’s a common belief that betas are buggy, as if it’s an inherent trait of the word beta. “Oh, issues like that are to be expected, it’s a beta.” I honestly disagree. A beta should be held to the same standards of stability; that’s the whole point. There may be design or functionality changes which aren’t yet finalised, but betas are not designed to be buggy. If I knew about a major bug, I wouldn’t release a beta until it was resolved.

Conversely, a full release is not automatically less buggy. These bugs don’t magically go away when the “beta” qualifier is dropped; they go away when they are reported and resolved. Releasing a hotfix immediately after a new version is one of the most demoralising and stressful parts of development. Those situations happen because the bug was only reported after release, not because we felt like scrambling to put out two releases back-to-back.

If you’re a beta tester of any piece of software and don’t often submit bug reports, I ask you to rethink your habits the next time a bug pops up. No matter how trivial, report it. You very well might be the first person to do so, and by extension have contributed towards making that piece of software better for everyone. Including you.

If you run systems that can’t risk beta software, consider running betas on staging systems, assuming you have them. If not, and you want to go the extra mile, consider a staging environment. It makes it easier for you to test beta software and decreases your overall risk when performing software updates.

The more users who are beta testing, and the more types of environments running beta versions, the more stable actual release software can be. When a major issue occurs in newly released software that went through a lengthy beta period, oftentimes this was due to a lack of reports, or a lack of beta testers who were actually impacted by the issue. So please, make those bug reports.

Conclusion

This is something I’ve been thinking about for a while but hadn’t quite thought of the right framing to write a post. The general disconnects between a bug being reported and being widely online. While I’m mostly talking about this from the perspective of open-source software, it’s also true of anything. Every setup can be unique in niche little ways; if you don’t report that bug, there might not be anyone else to do it for you.

Open-source software is almost always community-driven, and as a user, bug reports are your part in that ecosystem. So again, please report bugs; it matters more than you think. Open source thrives when everyone takes a little pride in contributing to its stability. After all, it is a truth universally acknowledged that an unreported bug will never be fixed.