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.

I am a User Interface Snob

What follows is a rant on a geeky topic that most normal people probably don't give a lick about. You have been warned.

One of my pet peeves is a poorly designed user interface, not just for software or web sites, but in physical objects, too. A common example is door handles in public buildings. The two kinds you encounter most often are the vertical handle and the horizonal bar that goes across the entire door. A person encountering the former will automatically tend to feel that the door should be pulled to open it, while the latter causes people to want to push it open. Yet sometimes, you encounter a vertical handle on a door that has to be pushed. They have to put a “PUSH” sign on it so that people will know they have to push it, and you will still be able to see people trying to pull it all day. Instead of putting up a sign, why not just use the right handle?

I ran into another one just now, when scanning a file with the AVG virus/malware scanner. It's nice that it scans for both viruses (Why aren't they called virii?) and spyware, but the results screen leaves something to be desired. It basically says something like this:

Infections found:	0
Infected objects removed or healed:	0
Not removed or healed:	0
Spyware found:	0
Spyware removed:	0
Not removed:	0

Every time that screen comes up, my brain has to sit there and figure out where I'm supposed to look to tell whether it found anything or not. The screen ought to look something like this:

NO BAD STUFF FOUND!

Then there's that recorded voice that tells you, “You must first dial a 1 before calling this number.” Why doesn't the phone system just pretend that you dialed the 1 and connect you? I mean, we have computers now! The system clearly knows what you meant, so why not just do it?

The best interface designers understand how to make things that just do the right thing with a minimum of hand-holding. They don't clutter up an already busy amusement park by putting up a sign that reads “Don't sit on the railing;” they just cover it with bumps or pokey bits that make it incredibly uncomfortable to sit on. They don't write software error messages that just tell you that it didn't like what you did for some arcane, programmery reason; they write ones that tell you what to do about it, or if feasible, make it impossible for you to make the mistake in the first place.

So what do you wish was better designed?

Bug Free!

I write code for a living, so the bug list is part of my daily life. Every day, I have a list that stares me in the face, reminding me of things that just aren't right. It's kind of like having a list of all your flaws in front of you every day. Some people might find that motivating, but the longer the list gets, the less motivating it seems.

The list tends to get very long when you're most of the way through coding a software release. It swells like a stream in late spring, full of the runoff of coding new features before you've had the opportunity to work out the bugs yet. Then the features are complete, and it's time to start hacking away at that list.

Of course, there are bugs and there are bugs. Most bugs are too important to allow the release to go out while they're still present. However, all software of any significance has bugs. To think otherwise would be like expecting gymnasts never to stumble. And sometimes you know about a minor issue, but for one reason or another the decision is made to release anyway. Usually, it's because the bug only inconveniences ourselves, not our customers, and the benefit of releasing outweighs the problems caused by the bug. But the bug sits on the list, waiting to be fixed.

The end of the release, when the bugs are supposed to get fixed, is often the time that someone decides to say, “Hey, did you guys know that Customer X needs Feature Y?” And so I get tasked on a new feature instead, and those annoying minor bugs continue to sit at the bottom of my list.

Not today, though! After weeks of hard work, today I can look at my list and see... no bugs! Of course, we're about to go into another round of testing, so we'll see how long that lasts.

Making some changes on the blog, trying out a different template and hosting options. Please excuse any template weirdness while I work it out.

Breaking Radio Silence

Sorry for the lack of updates. As might be expected, life got a lot busier after our son's birth. You may have heard that at his two week appointment with the pediatrician he was believed to be experiencing tachycardia, but when he had an electrocardiogram on Monday his heart rate seemed normal. We're still waiting for the official word from Primary Children's Hospital regarding the results, but it looks hopeful.

The other reason for the recent neglect of my blog is the fact that I have been spending a lot of time the last couple of weeks working late and muttering curses at web browsers under my breath. Turns out it's quite difficult to make an audio player widget that 1) works in Internet Explorer 6 and 7, Firefox and Safari; 2) detects Windows Media Player or QuickTime and uses either; and 3) can be dynamically added or removed from a page.

The infuriating thing is that this shouldn't be my job at all; the browser ought to be smart enough that I can just hand it some audio content and it will just figure out how to play it. The W3C and WHATWG finally got their heads together on the HTML5 standard which supposedly makes embedding media easy, but I'll probably be dead before support is widespread enough that I can actually use it.