A bug is something that was working earlier but now isn’t. That’s it. Everything else is a feature.
In the rest of this essay, I will try to justify this definition, and also state why it matters (spoiler: it doesn’t really, except as a way of thinking about things (that’s what’s called philosophy, Manav)).
This definition might seem like a very low bar; au contraire it is too high. Rare are projects that (strictly) satisfy it — Linux, Windows, the “Web”.
And whether or not to satisfy this definition is a business decision, not an engineering decision (engineers left to their own would do anything except fix bugs). By business decision I mean that someone with power deliberately made the choice.
I haven’t yet mentioned what “satisfy it” means. Well, it means once you define bugs this way, you make sure all bugs are fixed.
That sounds like a good thing to do, why doesn’t everyone do it? Unless you’re among the perennially outraged, you’d understand how it is a trolley problem (as the philosopher in me is saying), or how “it’s a tradeoff” (as the engineer chimes in).
There is a very high cost to unconditionally fixing all bugs as defined this way, and rare is it that circumstances warrant such strictness (as our empirical difficulty in finding real world examples illustrates).
The advantage though is that it sets the direction of evolution. The software then cannot get worse. It can remain bad, with new garbage being continuously added (as I’m told happens with Windows), or it can go into a dull stupor (as happened with the Web for a while before it somehow woke up again in the last decade), or it can slowly but steadily rise and rise (Linux); but it can’t get worse.
This is a ridiculously good thing, but people (as is our wont) are not happy with it. We want more.
All of these get classified as bugs (by the reporter, not necessarily the developers) in the common sensical vernacular definition, but none of them would be bugs in the definition I’m talking about unless they were working earlier.
The problem with wanting more, without a plan, is sometimes then we don’t even get less.
As a programmer I’m painfully aware of my ability to produce bugs. Having gone through the 7 stages of grief multiple times, I have come to accept that I will produce bugs from time to time no matter how meticulous I am.
There are things I can try to help reduce the chances (of the various medicines floating around, only static types and end-to-end tests seem to help), and I adopt them whenever circumstances permit. Still, unless I go full NASA (say by drastically slowing down and/or involving multiple people for parts which need extra care), in the day to day scheme of things, the chances are still there.
In such as the universe, I’m extremely grateful to QA people or users who let me know of a recent regression I introduced. Really, thank you.
The context is fresh in my mind and I can make the connection between what I did incorrectly and its manifestation easily (making that connection otherwise gets harder as time goes). A bug once reproducible has no defenses (unlike their organic brethren), so I can quickly fix it too and restore my balance with this universe of not doing more harm than good.
What makes it harder to quickly fix them is when these regressions get mixed in among feature requests masquerading as bugs (or perhaps I should just call them non-bugs to avoid triggering the easily triggered).
What’s ironic is that the reporters who insist on classifying their pet thing as a bug, since they feel it will get more attention that way, end up losing visibility because the higher ups usually pay more attention to feature requests than to bugs.
So it’s a lose lose for everyone when someone classifies it as a bug a thing which was not already working.
I’m far from the first to recognize all this, though I may have
been the first to waste spend a Saturday evening writing a rant
about it.
Indeed, while strict conformance to the definition I’m using is rare, for most well run projects that have long term horizons, paying extra attention to regressions is very common. Some will even speak in similar terms. For example, Electron will often not consider your report as a bug unless you fill in the last working version and provide a reproducible example, but if you do both, a fix would land quickly.
Another thing I like about this definition is that it sidesteps subjectivity. With regards to how something should work, what is obviously wrong to some user is more often than not a myriad of tricky interrelated aspects they’re only iceberg tipping off. On the other hand, it is usually reasonably clearcut when something which was working earlier now stopped working, and the reasons are one of:
The second one is called breaking backward compatibility, and e.g. the rare projects I mentioned above almost never do it, though that’s why they are rare.
But it is not my flag to defend or burn, the second one. Here I’m only talking about the first category, and having them stand out would help me with the (personal) no regression rule I try to follow. That for me would be the value of a more precise definition of bugs.