I hate “bug”. Not “bug” as in “terrestrial arthropod”, but “bug” as in the term used to describe software problems.

Software engineering might be just about the only “engineering” discipline where the presence of – sometimes critical – errors are just taken as a given, and there is this culture of accepting it with either muted indifference at best, or jokingly at worst.

I hate the term because it diminishes the impact of what we do. I hate the term because it shows we don’t take ourselves seriously.

Bridges don’t have bugs. Buildings don’t have bugs. Roads, hammers, pens, or shoes don’t have bugs. They have structural flaws which are foreseen, planned for; if they do materialize, there are usually punishments for their creator. In the worst cases, commissions are formed trying to figure out how and why the flaw happened, and how we can avoid having it happen again.

The desk I’m using currently is more than one hundred years old and belonged to my great-grandfather. It doesn’t have “bugs” because the craftsman who made it set out to make a functional, sturdy desk. If it failed somehow, if a piece was out of place or a sometimes was poorly joined, I’d wager he’d be devastated; he wouldn’t slap his knees and say “ah, well, bugs happen :)”.

Why can’t we have this professionalism? Why is it a given that the software we write will have flaws that we can’t model? Why do we paper over this with a cute-sounding word like “bug”? Software problems cause real world damage, you know?

What others words could we use?

So “bug” is out. What to use then?

• Problem: too generic. A program can be correct but have an efficiency problem, for example. This doesn’t really hone in on the type of issues we’re talking about here.

• Error: not bad, but already means something specific in software engineering… in my mind, “error” is a term used to describe program logic, not a meta-term used to describe the context around the program itself (e.g., “use exceptions to handle errors”).

• Mistake: focuses too much on the human side of the problem. It’s inevitable that people will make mistakes, but this doesn’t mean that the end result should be that the problem is faulty – mistakes should be foreseen and proper processes be put in place to correct them and mitigate their impact.

• Fault: sounds a bit old-fashioned and has some use in distributed systems, but is free apart from that.

• Flaw: negative enough to give the proper impression of seriousness, but not so exaggerated as to lose its impact after you’ve said it twenty times.

At work, I’ve been trying to use the term “flaw” – “there’s a flaw in program”. It is a bit nerdy and definitely uncommon, but at least it perks peoples’ attention to the fact that something serious happened, that a real person had/will have a real hardship due to this flaw, and the blame for that lies solely with us, the creators of the program, rather than with the moth in the Mark II relay.

Tags: #engineering