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. I ramped up quickly as a developer (i solved my first bug on my second week) from early on i branched to doing functional work, covering for pdas when they could not do/did not know how to do their tasks.

I took ownership of an internal tool, critical for development/testing that we do. I improved this tool with new functionalities and documentation.

I was put on the maintenance team 3 months after joining (very rare). For that trimester, we had a new maintenance record low of just 10 records in our backlog.

My proactiveness caused me to be promoted to team leader/manager in April, 7 months after starting. I was put in charge of all PIO’s and SIO’s NDCX maintenance activities, as well as baseline PIO’s travel distribution maintenance activities. The team increased afterwards, taking in also PIO-Bangalore (India), which made me responsible for all maintenance activities in our agile train. The team will increase again for the following trimester.

I became the point man for maintenance activities in the train, and increasingly in the department. I am contacted by directors, managers, senior managers, service account managers, scrum masters, solution experts, and project managers. It is my job to juggle all these (often competing) priorities and direct the team to work on those records with have the highest impact.

I work very closely with the principal QA manager for the entire NDCX project, where I serve as his replacement for when he’s OOO. I do scrum master activities for my team, where I plan iteration reviews, retrospectives, hand-offs, and clarification sessions. I lead daily standup meetings with all my teammates, separated by functionality. I also do product owner work, given that I am the first stop for functional knowledge in my team. I also communicate closely with other product owners, teaching them things about the products we manage. I have a close cooperation with project managers, where I clarify features for them. I suggest/propose new features to be developed by the scrum teams, and I participate in the feature triage process by providing evidence-based justifications for which features the teams should focus on developing.

Despite only being dedicated 50% (formally; realistically it takes 70% of my time) of the time to actual maintenance activities (solving records), I have the highest output of all the members in the team.

Tags: #engineering