Why is the term “bug” very negative to some? [closed]
-
13-03-2021 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Our software user interface was originally written in another language. Some of the English translations are poor. When I raised one of these as a bug, the manager got angry with something like "this is not a bug, but a possible improvement".
We might argue over severity, priority, re-categorise it, address it immediately or in a future version, or even ignore it altogether. Whatever. If you cannot fix it immediately (because it affects documentation for example), just write it down and move on.
To me "bug" is just a general catch-all for "error", "undesired behaviour", "fault", "defect", etc. It is entirely neutral, even positive. Its been helpful over the years to describe issues, without getting into complicated, sometimes heated, conversations about what exactly is meant by a specific term.
Most colleagues are unaffected by this storm-in-a-teacup, but over the years a number of engineer and manager colleagues will wholeheartedly agree that X is an "issue", but get insistent (often angry) if X is referred to as a "bug". The offense seems to be specifically with the word "bug". Why? Its just a word. Most software has many, mostly minor, bugs. Is there some special meaning to "bug"?
What is the best general practice to:
- be more diplomatic and defuse tension over terms?
- improve the chances an issue, however described, will actually be fixed sometime in the future?
Solution
This question is surely opinion-based, but I've noticed this reaction as well. This question might be more appropriate for The Workplace, but even then it might not be the best fit.
The term "bug" is not offensive. As others have pointed out, a bug is an unintended behavior that deviates from the intended behavior. Bugs happen. As for why people gets so upset about reporting bugs?
Politics.
A bug is a mistake. Mistakes are negative. Negative actions have professional consequences, such as missing a promotion, raise or just being chewed out by upper management. To "file a bug" is tantamount to accusing some people of being careless — perhaps an entire team of people. Basically some people view it as an insult or an accusation. That's all.
OTHER TIPS
It is extremely helpful to categorize software issues (bugs, errors, ...) based on which expectations aren't met and on which documents these expectations are based. If the software does not behave as specified you could clearly label that as a bug. If it doesn't behave as documented you'd need to check whether the documentation promises something that wasn't specified, in which case there's an error in the documentation. The most difficult cases are implicit assumptions, as some are clearly justified even if not explicitly specified or documented (the software should not crash when I enter bogus search words,) while others only seem obvious to the user but were never part of the specification (search results should be sorted by popularity, or navigation results should show this and not that route because that route is currently affected by roadworks.)
Once there is a common understanding what categories there are and how they're properly handled, it's much easier to find names for each that work for all affected parties.
To me, anything that any user has a problem with is a "bug".
Well, then you are using the word incorrectly. See for example Wikipedia:
A software bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
A bug is the mistake a developer made either in designing the system or in implementing it.
If I was hired to build a system to a specification and the specification says "Users cannot delete their content" and you file a bug that says "But users want that, that's a problem", then I'd think you do not really know what the word "bug" means.
Next time, before you file a bug, look up what the specified behavior actually is. If you can find a specification that says you are correct, it was planned to behave differently, then file a bug. Otherwise use a different term. Improvement? New Feature? Issue? Depends on your organization.
I like to think that software developers should be understanding about bugs. Its their job. The one time it could get touchy is if a developer was forced to put their name on a piece of code that was poorly specified and they feel the feature was ambiguous from the start.
From a managment perspective, there is politics to consider, as Greg mentions. Often the business world is built around arbitrarily drawn lines in the sand. An improvement to the software runs through a different path than an error. For example, an error might involve notifying all of the users of your software that the bug exists. That can be expensive, both in terms of actual cost and "good will."
This is, of course, a slippery slope -- a dangerous game. A manager who abuses this approach to hide bugs can cause grief for the company later on. However, if a skilled manager knows his or her clients well, he may understand that this particular problem can be solved unofficially for far less cost than marking it as a bug to be solved officially. Or perhaps the business has multiple pools of money, where bug fixes must come out of one but features come out of another. The difference between a bug fix and a feature request may be whether they can make the fix this quarter or next quarter depending on which way you round the ambiguity. This is a business decision, and an ethics decision. For example, if the problem has not caused any problems for the customers yet and you know the customers always move to the latest version when you release it, and you know the customer cares about getting this fixed fast, it may be better to resolve the ambiguity towards a feature request.
While a developer should absolutely care about how the business works and have input into how things proceed, there is definitely a reason the manager exists in the first place. If you are interested, try to approach the manager and find out why they push these decisions. If you feel ethically bound to call it a bug, you may learn the correct language to use to convince the manager to agree it is a bug as well.
Some things will always be bugs. For example, if there's a buffer overrun, the only way that could possibly be a feature request is if the customer had previously not cared about security and is now in the process of shifting their stance to care about security. Another example might be an algorithm that runs non-deterministically when it had previously been sold to the customer as a deterministic algorithm.
Bugs are prioritized differently, given different resources, planned differently, tracked differently, reported to customers differently, and closed differently than enhancements. Completely aside from the pride issues others have mentioned, when you mischaracterize a work item, there is a whole process ripple effect you set in motion. This is especially vexing to someone whose job is to manage that process.
If the ticket started and ended with you, it wouldn't matter so much. It's just a task you're working on. On my personal projects, I usually just create a GitHub issue to remember work to do and don't care about labeling it a bug or not. When other people are involved, it's courteous to be more precise.
