Pet Bugs

Just about anybody who uses a computer regularly will have accumulated one or more “pet bugs”: little annoyances in the software they use, forcing them to find some way around the problem. The more they use the software, the more the bugs bother. Sometimes a bug survives several significant updates to the software, and the user begins to wonder, “Why on earth hasn't this been fixed already?” Well, I'm here to tell you why.

I can empathize with the sentiment. I have my own collection of pet bugs. But as a software developer, I also live on the other side of the issue. Many times, the developer simply doesn't know the bug exists, and if they did, they'd rapidly fix it. Other times, they are aware of the bug, but—as unfathomable as it might be for some users (and software process gurus)—they have decided, at least for now, not to fix it. Usually the reason is rooted in a problem faced by nearly any software project with a significant user base: the astonishing pile of feature requests (most of them considered “high priority”) versus finite developer resources. Somewhere, amid all that, they've got to fix bugs, too. Because of this, they tend to rationalize why some bugs can be left unfixed, with varying degrees of legitimacy. Over the course of my career, I've heard a number of different rationales; here are a few:

“Almost nobody will be affected.” It's sort of an inverse of “The Starfish Story.” It's no problem for almost all users, but the ones who do experience it are significantly cheesed off. The rationale would be better expressed as, “It is a valid problem, but there are other things we could work on which would result in a greater total benefit for our customers.”

“Yeah, but when's that ever gonna happen?” The very act of uttering these words seems to guarantee that the exact scenario in question will happen. The Y2K bug fell into this category: those who developed the software never dreamed that it would remain in use for so long without eventually being replaced by something more modern. Incidentally, another such event looms on the horizon: lots of applications (and some operating systems) store time as the number of seconds since January 1, 1970, but the storage space is only sufficient for 2,147,483,647 seconds, meaning that a Y2K-like problem is slated for January 19, 2038.

“If that ever happens, we'll have bigger problems to worry about.” Fairly justifiable, if it's really true: “Yes, emails will fail to go out if our server farm is hit by tactical missile strike, but if that ever happens...” It reminds me of a co-worker's story about someone he knew who was required to design a simple, mechanical button... which could still work after a missile hits the building. I'm not kidding. (I have a feeling that whatever it is intended to do, the button itself is probably large and red and surrounded by black and yellow diagonal stripes.) It's a reasonable requirement for military applications, I'm sure, although you might end up with a situation where the button is perfectly functional but nobody has survived to push it. As for the rationale for fixing the bug, one could always argue that if you do have bigger problems, wouldn't you like to have one less?

“If that ever happens, we'll be discussing this on a beach in the Carribean.” An only half-serious rationale: the problem would only arise in a situation where the product was so wildly successful that those involved would all be fabulously wealthy. The speaker asserts that not only can the fix be put off, but that when it reaches the point where it must be fixed, they could probably delegate it to someone else so that they could continue sipping their tropical beverages. Often termed “a good problem to have,” but responsible developers are forward-thinking and will head the these issues off beforehand, when possible. The last thing you want is to be killed by your own success.

I still am tempted to revile my pet bugs. Being a developer, I ought to know better. I ought to remember that somewhere there's a developer who would love to kill that bug if there were just more hours in the day. Except that if there were more hours, he'd probably use them for other neglected things, like taking out his will, or changing his oil, or getting a physical.

As improbable as it seems, it turns out that software developers are people, too.