In their book The Art of Agile Development, James Shore and Shane Warden discuss the “bug blame game,” where a programmer responds to issue of a bug being found by retorting, “That’s not a bug. It’s a feature!” James and Shane note that there are those who have taken the definition of a bug to extraordinary heights, classifying bugs as defects, faults, errors, issues, anomalies, and unintentional features.
I’ve encountered another variation on this theme, and usually surfaces in an unproductive argument between business and development. It starts innocently enough, and begins with a query to development to “see what the code is doing” in response to some action a user is taking.
Translation: The software is behaving in a way that someone does not expect, and they want to confirm that behavior – although it is clear that they don’t like that behavior. Often times, there is an unstated hope that “looking at the code” will reveal some other option that will enable the business to perform the desired behavior.
When a programmer examines the code with respect to the issue being described, often times the report is what initiates the combative portion of the conversation, “Functions as designed!” the programmer responds.
This is when the business side grits their teeth – they’ve just heard that the software isn’t doing what they wanted it to do, and now they are hearing a phrase that leads them to believe that programmers are delighted about confirming that the software isn’t working correctly.
What is going on? Why would a programmer appear delighted?
The programmer’s point of view in this scenario is very different. The programmer was approached with a concern – there was uncertainty about how the software is functioning in a given situation. The programmer feels glad to have researched and found the "answer," that the software wasn’t designed to perform as the business user described. In the programmer’s mind, the issue is now crystal clear.
The business user, however, is disappointed. The business user responds by saying, “Well, the software should be doing X, and because it isn’t, it is a defect.”
The battle lines between business and development are drawn. Unless someone is around who recognizes what is going on and can interject themselves appropriately, a useless argument about whether the issue at hand is a defect or enhancement is about to take place. The business user will continually assert that because the software isn’t doing what is expected, it is a defect. The programmer will retort that because the software was never designed to operate in the way the business described, the requested functionality is really an enhancement.
The heart of the matter is less about the nature of the problem and more about effort required to resolve the problem.
From a programmer’s standpoint a defect means that there is a problem with how the software is operating – it performing an operation that it was intended to do, but it is failing to do so in some specific way. There is an adjustment that needs to be made, but it doesn’t violate the overall design and intended behavior that is already represented in the code.
An enhancement means something else entirely to a programmer. There is behavior that must be understood and agreed upon, and that behavior must not contradict behavior that is already present in the software. That behavior must then be designed, coded, and tested – along with tests to ensure that other, related functionality is not impacted.
From a programmer’s point of view, a defect is much easier to resolve than an enhancement. Since business users are not programmers, it is best that someone on the development side of the house explain what needs to come next, and why; it turns what could be an adversarial situation into a partnership where both parties understand and agree on the problem what it will take to resolve the problem.