The bug that wasn't
Have you ever bumped into the meme: that’s not a bug, it’s a feature!
There are a lot of ideas and emotions attached to this particular meme.
In this post I’d like to ponder on one concept that the meme entails. I’ll start with a question:
What about the bugs that are still bugs, but if we’re honest, they’re garbage!
Meaningless bugs. We’re sad thinking about the precious time we drowned reporting them in the first place. What do we do about these bugs?
Most folks will say: we can ignore these.
Fine. Let’s ignore garbage bugs for a moment.
Some will point out that ignoring bugs, any sort of them, is dangerous. I’m inclined to agree, generally it’s not a good idea to ignore ANY bugs.
In most of the contexts that’s usually the resting place of garbage bugs: Oblivion took them. So we ignore meaningless bugs. They fade away in whatever ticketing system we endured at the time.
Dangerous or not, the act of ignoring bugs is not without consequences.
Ignoring bugs means: Meaningful bugs put next to garbage bugs, that we never got around to fix. Bugs that keep us up at night. Bugs we already forgot about, that weren’t trash. Some important. Some a minor nuisance. Some we chose to live with for any given reason. All these bugs, they too fell into Oblivion.
But… if a bug ends up resting with bugs that were garbage… Aren’t they garbage too? Some will say: No, of course they’re not garbage.
The conversation soon starts to turn into a soup of logical fallacies. We’ve entered the realms of arguments and counter-arguments.
For the idealistic, the point remains: If the bugs we forgot about weren’t garbage, we should have fixed them.
Oh, But we couldn’t! Due to
<insert some excuse here>
To which some pragmatic, or cynical, survivors of software development trauma will reply:
If we couldn’t find, or advocate, for a good enough excuse to fix them, then they were garbage.
There wasn’t enough time, or attention. If only some conditions had been better. It’s a terrible thing for testers to come to terms with: abandoning a bug.
Out of the blue, to the tune of a 90s Rock Wrestling theme, rolling in dressed with full body spandex:
OH MY GOSH! IT’S THE BUG WE ABANDONED! APPROACHING THE RING WITH A STEEL CHAIR!
The problem of putting everything in the same bucket
The question never ends up being about abandoned bugs still being worthy bugs. It’s not about entering a discussion on truths about bug classification from good to garbage. If we get to that point, we’ll lose ourselves in dialectical smoke.
The real deal question that keeps some Testers awake at night is:
Bugs can be ignored, omitted or, jokingly, considered as a feature… until they can’t
We tend to forget to factor in Time as a variable or descriptor of bugs.
Consider a bug through the lens of Time. There are so many different measures:
- Lifespan,
- Expiry date,
- Frequency,
- Fuse-length,
- Residual damage (long lasting damage of software bugs, like Nuclear fallout)
- …
We may think back to all the bug reports we’ve have filed at different jobs left unfixed. Some of those will no longer be relevant. And some have acted up or will act up in unexpected ways still.
Time - An example
On this notion of Time, I’d like to take you back to an actual bug that wasn’t until it was. There are plenty of examples to pick from. Some are tragic and serious. Some are comical. I’ve decided to pick one I experienced myself.
By all official accounts, it wasn’t considered a real bug. Until someone from the community had had enough and fixed it.
Long story short:
- There was a bug that plagued a popular game, unacknowledged by the developers;
- The main symptom of the bug was that a mode within the game took longer to start. So, it only harmed some of the loading times;
- For years the gaming community complained about the symptoms. The hardware systems folks played on kept evolving, but loading times didn’t reduce.
- Some folks “defended the developer’s bruised honor” for years. They would advocate that the real problem wasn’t the slow loading times. The problem were the gamers that were not patient and complaining. Other than the life-consuming looooong loading times, gamers should be thankful;
- The developers had no reason to fix the problem. Other than the noise and complaints from the community.
Keep in mind, this game was successful enough that people still bought it. People kept complaining. Money kept flowing through. It didn’t matter: at the time of writing, this is still the second best selling game in the world. Gamers have a bond with the game, despite the imbalance in the game’s loading times.
In comes an outsider, a member of the community. They reverse engineer the game’s code and manage to find the actual bug. They even manage to reverse engineer an unofficial patch that fixed the issue.
The news of this feat broke fast. Every single video-games related newspaper and magazine was on it. And soon the developers and publisher posted an official fix. And also thanked the community member.
The Tester in me is willing to bet that the same bug:
- Was reported, internally, more than one time, by testers.
- Had been likely ignored for years.
- And to this day, no official patch would’ve happened. If not for some outsider pointing to the problem publicly.
And I’m willing to bet some folks internally even wanted to fix the problem. But it was forbidden fix. It couldn’t happen. My suspicions, not the facts:
- There were enough resources to fix the issue way sooner;
- Whoever had the power to arbitrate the decision of fixing this issue… decided not to do so. Or postponed the decision for as long as they could.
All it took was time. Time for the bug to become real, in other words, validated.
Roughly 7 years if you start counting since that particular game’s first release.
Wrapping up
Time likely wasn’t taken into consideration by whoever chose to ignore the bug. The bug was, for better or worse, tucked next to other bugs, some of them garbage, some of them features.
This story is not singular or unique. There are more stories similar to this one. The details or the kind software is different, but the tone is the same: a bug that wasn’t, but was.
There are stances we can take in development that are prone to breed these types of “Schrödinger” bugs.
There’s to much to break apart on this, I will return to it and look at these systems in upcoming posts. For now, and for this post, there’s a guiding principle I would like to leave readers with:
A bug’s state is always affected by the dimension of Time
If you read this far, thank you. Feel free to reach out to me with comments, ideas, grammar errors, and suggestions via any of my social media. Until next time, stay safe, take care! If you are up for it, you can also buy me a coffee ☕