Home > Software & IT > Coding Horror-ibly

Coding Horror-ibly

2008.11.25

I love Jeff Atwood’s blog.  But sometimes, I think he’s smoking crack.

His latest post, “That’s Not a Bug, It’s a Feature Request” gets it way wrong.  Regarding Bugs versus Feature Requests, Jeff writes:

There’s no difference between a bug and a feature request from the user’s perspective.

I almost burst out laughing when I read that.

Jeff goes on:

Users never understand the difference anyway, and what’s worse, developers tend to use that division as a wedge against users. Nudge things you don’t want to do into that “feature request” bucket, and proceed to ignore them forever. Argue strongly and loudly enough that something reported as a “bug” clearly isn’t, and you may not have to to do any work to fix it. Stop dividing the world into Bugs and Feature Requests, and both of these project pathologies go away.

I’m not sure what kind of “users” Jeff has to support, but in my universe, there is a very clear difference between “Bugs” and “Feature Requests” which users clearly understand, and which Jeff would do well to learn.

The difference is simple:

  1. Functionality that was part of the specification (i.e. something the user paid for) and which fails to work as specified is a Bug.
  2. Functionality that was not part of the specification (i.e. something the user has not paid for yet) is a Feature Request.

I confess that the vast majority of my experience comes from designing, creating, and supporting so-called “backoffice” applications for companies like VeryBigCo.  And believe me, at VeryBigCo, users know what they need to get their work done, and demand it in the application requirements.  If the application does not meet requirements during UAT, or stops performing correctly in use, then the application is defective.

But what about shrink-wrapped apps?  Do users understand the difference between a bug and a feature request?  In a recent discussion thread on the Sonar forum, a set of users were complaining that a refund is in order because the company focused on “New Features” instead of “Fixing Bugs” from the previous version.

So we can lay to rest the question of whether users think of Bugs and Feature Requests differently.  They do.  And users expect fixing bugs to take precedence over adding new features.  The next question is: should “bugs” and “feature requests” be handled differently from the development point of view?

Let me answer that question with another question: should all items on the applications to-do list be handled with the same priority?  Should Issue #337 (Need “Right-Click to Copy”) be treated with the same urgency as Issue #791 (“Right-Click to Copy” Does Nothing).

Apparently, in Jeff’s world, they should.  Bug?  Feature Request?  It’s all just “stuff that we need to change” so let’s just get right on that shall we? According to Jeff, if we just drop the distinction, then it all goes away.

But how can it?  In the first example, the application doesn’t have a “Right-Click to Copy” feature, which is a good idea, so we should add it.  In the second example, we committed to providing a “Right-Click to Copy” feature, and the user paid for it, but it isn’t there! Does Jeff really think the user is ambivalent to these two situations?  Not the users I know.

There is yet another point that Jeff misses: continuous improvement.  The fact is, if we aim to develop defect-free software, we have to start by understanding our defect rate.  The simple fact is that a Bug is a defect, and a Feature Request is not.  Ignoring the difference means ignoring the defect rate, which means you can forget about continuous improvement.

Furthermore, if you’re doing a really good job at continuous improvement, then you care about the distinction on a finer level and for an even better reason: it helps you understand and improve

  • defects caused by failure to transform stated requirements into product (“development defects”, a.k.a. “bugs”)
  • defects caused by failure to capture requirements that should have been caught initially (requirements and analysis defects that arrive as “feature requests” but which should be reclassified as “requirements defects”)
  • non-defect feature requests – good ideas that just happened to emerge post-deployment (the real “feature requests”)

The only valid point to emerge from the cloud of hazy ideas Jeff presents is that it is unconstructive to use the Bug versus Feature Request distinction as a wedge against users.  It is true that bedraggled development teams will often try to conceal the magnitude of their defectiveness by reclassifying Bugs as Feature Requests.  But this is symptomatic of a far larger problem of defective project / product management, not overclassification.

I’m reminded of an episode of The Wire, in which the department is trying desperately to reclassify homicides as unintentional deaths to drop the city’s murder rate statistics.  Following Jeff’s reasoning, the better solution would be to drop the terms “homicide” and “manslaughter” altogether.  “Stop dividing dead people into Homicides and Involuntary Manslaughters, and both of these human pathologies go away.”

Right, Jeff?

Advertisements
Categories: Software & IT Tags:
%d bloggers like this: