Mediocrity Begins at Home

There’s no shame in bugs.

Really. In consumer-grade software, there are bugs. I wish it wasn’t so, but it is so. I can’t think of a product I’ve used in the past 20 years that hasn’t had a bug or two. There are a few different reactions to finding out that your product has a bug. One of those reactions is to say nothing at all. While this often displeases the peanut gallery, sometimes it’s the wisest course. Another reaction is to acknowledge the bug and move on. “Oh man, you’re right. That sucks. I hope we can get that fixed soon.” I think that’s usually a pretty good response, although it may give your lawyers a conniption fit.

Then there’s what I have come, over the years, to think of as “The Linux Answer.” That’s the one where you blame the user for wanting to use the product in a way which exercises the bug.

User: “The kernel’s interface for force unmounting the filesystem is broken, and it can’t ever possibly work.” Developer: “Why are you trying to force unmount? You shouldn’t try to use that API, even though it’s documented and no bugs are filed against it.”

User: “The performance of the threads implementation on your OS is an order of magnitude worse than the one on these other OSs when I run any app that uses a lot of threads.” Developer: “Threads are stupid. You should rewrite all your code.”

It’s not really fair anymore to call this “the Linux answer,” because of course overzealous fans of any product sometimes have this sort of reaction when confronted with its shortcomings. As a developer, I find that I get possessive of the code I write. Someone will ask me how a component I’ve contributed to acts when given certain inputs, and I’ll find myself saying “well, when we get this request, we apply these policies and then give this answer back to you.” And then I’ll stop, and listen to myself referring to the code I wrote in the first person, and have to smack myself in the head a few times.

I suspect that it’s this sort of anthropomorphism of software that causes The Linux Answer. Some level of identification with your code is inevitable (it provides a convenient conversational framework, if nothing else). But when it reaches the point that you’re willing to blame the user for criticizing your code (because the user is therefore criticizing you, which wounds your feelings) – well, look. It’s just code. It has bugs. Fixing the bugs is good. And you can’t fix the bugs unless you know about them.

So the right thing to do when a user tells you about a bug is to thank her.