Perhaps you’ve already encountered this:
-
a user complains about a bug of their favourite (or not) software,
-
a developer states that it works as designed and declares it to be an enhancement request,
-
the user is angry, because it’s "obviously" a bug and not an enhancement, how can any sane developer think that such a behavior is normal?
-
Starting from there, the situation can escalate at will between user and developer, each accusing the other to be a clueless nincompoop.
Sounds familiar? Yes, it does! I’ve seen this happen numerous times, while being on the user side, on the developer side, or as innocent bystander.
As often, it helps to try to understand the other side before taking a too strong position (by risk of being after all the one true clueless nincompoop). So let’s do this.
From a user perspective, the situation is quite clear:
the software doesn’t do what it’s expected to do, it’s a bug.
It would be only be an enhancement if it required a new feature.
The feature is there, it just doesn’t do what it’s expected to do, so it’s a bug!
This is the external view of the software, but this isn’t the internal one. And it is mostly this last view which the developer sees, unless they’re their own user, but that’s another story.
The internal view of the software is the design and source code view. The design is, simply said, the plan how the software should work, and hence the description of how the source code should be written, which will make the software work as it’s supposed to do.
Now, when a developer says that the software works as designed, they’re simply saying that it works according to plan.
The plan/design might be utter garbage, but it has been followed, and so it’s an enhancement and not a bug!
|
Note
|
Based on my experience, there is not always an actual design, but the source code represents the design, and it does what it’s supposed to do. Again, it might not do what it’s expected to do, but it does what it’s been written to do (if you get the subtile difference). |
If we take the car industry as a more concrete example, a bug might be when a car loses one of its wheels in curves, whereas a 3-wheels car which is less stable at high speed than a 4-wheels car would be deemed working as designed. And this even though any sane car driver wary of their bodily integrity would expect their car to be stable.
Being aware of the differences in perception is the first step to communication. How do we now bring those two different views together?
First it’s important for users to understand that behind the statement that something isn’t a bug but an enhancement, there is the implicit recognition that implementing the admittedly necessary fix might be more complex than a simple code fix. Going back to our car example, better fixing of an already existing wheel is probably a lot easier to achieve than adding a 4th wheel to a 3-wheels car.
Then, where a bug is generally absolute in the sense that there is little doubt that it must be fixed (who wants to lose a wheel?), changing a design might have consequences which need to be weighted in terms of technical and other (financial, effort, …) tradeoffs. Those same tradeoffs might (should!) even have been considered as the initial design was decided, and support the statement that the software works as designed. For example a fourth wheel might make the car more expensive and heavy, which would need to be weighted against the advantage of being able to drive the car faster more securely.
This tradeoff consideration must also happen in the context of the customer/user demand: is the majority more cost conscious or accepts a higher price for the advantage of a more stable high speed? Is feature richness more important than execution speed of the software, or vice-versa? Etc. Declaring an issue as enhancement request allows to keep the topic open longer, gather user feedback and decide on priority based on this feedback.
On the other hand, the developer can improve their communication and more clearly state what they mean. It might also not hurt to admit that badly designed software can be a bug, especially if the impact of a certain design decision wasn’t considered. In my opinion, there is a difference if the stability impact was considered and weighted against the price of a 4th wheel, or if it was just "discovered" once implemented. In the first case, it would rather be an enhancement request, in the second rather a bug. This said, the price impact of implementing a fourth wheel hasn’t disappeared because the stability impact hadn’t been considered, and one might still decide that the former overweights the latter, and declare the latter to be an enhancement request, to be thorougthly considered before being implemented.
And it is in my opinion how such a situation can be fairly handled:
-
if the (negative) impact was known and considered during the design phase, it is definitively an enhancement to revise this decision,
-
if the impact wasn’t considered, then the (tricky) question becomes: would the decision have changed, had the impact been identified at that time?
-
if yes, then we probably have a bug to fix, though perhaps a non-trivial one
-
if no, then we’re facing an enhancement request
-
As a conclusion, proper communication helps as always, and a stupid design decision remains a bug.
There is probably a reason why slow cheap rickshaws have 3 wheels, and fast expensive cars 4 of them. But, whatever the speed, you don’t want to lose a wheel, whichever their number.
I don’t chirp, I horn now, so let’s horn together!