Stop Calling these ‘Bugs’

Zachary Keeton
2 min readNov 30, 2020

--

I'm really careful about labeling things bugs in the code. Because to me, a bug is a failure of a software developer to do their job. Their job is to write code to satisfy the given requirements. If they’ve failed to meet the given requirements, there is a defect in their craftsmanship which we call a bug.

Normally though, what I have seen most often is that a developer will get a feature request with 5 specific requirements. The developer will then write fully unit-tested code that fulfills those five requirements and everything's fine. However, the QA team, using the product in ways that resemble a normal user, may object with what is essentially a new requirement. For example, “It should also behave this way when you go to another page and then return. We shouldn’t release it until this extra behavior is added [marked as BUG]”.

The example above is actually extra behavior that is essentially requirement #6, an additional requirement to the first five. When they write that up as a bug though, they are implicating the developer. I take issue with that because it was basically an unknown/unlisted requirement, so it is either a design/planning failure or totally unforeseeable. Either way, the developer did faithfully execute their task to code against the given requirements. Giving them an effective demerit (saying their code was defective/BUG) is unwarranted and unfair in this situation.

To my mind, it’s only appropriate to label something a bug when the code fails to meet the explicit requirements known at dev time. We need a new name for these other things: “missed requirement”? “extra requirement”? “feature request”? “design gap”?

--

--

Zachary Keeton
Zachary Keeton

Written by Zachary Keeton

A 15th-year Web Dev/Engineering Manager. Formerly building products and leading teams at Plus One Robotics in San Antonio, Texas, USA

Responses (1)