10 June 2017
Call them programming errors– not bugs.
Calling them “bugs” is at best hearkening back to era of electro-mechanical devices, possibly the early era of vacuum tub computing, or at worst is a denial of responsibility.
If you wrote the code that contains the mistake, take ownership of that fact by identifying it as a programming error– your programming error.
Maybe it was an error in logic. Maybe it was a typo. Maybe a related but incorrect function was invoked. Maybe it was an error of omission. Maybe something from the criteria or specifications were misstated or misunderstood.
Identifying mistakes as bugs, some go all the way and use anthropomorphic terms, give them names, and contemplate their personality disorders. References to pathological bugs, stubborn bugs, persistent bugs and so on, are often heard at status meetings. This emphasizes the wrong mindset.
People make mistakes, so get past this.
Calling our errors “defects” is no better because it still displaces responsibility.
Own it!
Rather than striving for perfection, focus on excellence. This means you don’t have to be completely correct the first time. Instead, overcome any obstacles and persevere.
By focusing on excellence, group dynamics will change.
Software developers as with those in other fields that have worked in multiple different groups may know a particular character: typically male, he is prolific at generating releases and holds a record for number of bugs resolved. That is, he wrote the code that introduced the bugs and then fixed his own mistakes, likely introducing new programming errors in the process. The cycle continues.
In a healthy work environment, such shenanigans should be called out.
The first step is to call them errors, not bugs and not defects.
