Nov
25
Written by:
Rip Rowan
11/25/2008 11:44 AM
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: - Functionality that was part of the specification (i.e. something the user paid for) and which fails to work as specified is a Bug.
- 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?
Tags:
6 comment(s) so far...
I think the users Jeff has in mind had no part in writing the specifications; the product they paid for was likely off-the-shelf software. They have no idea how the product is *supposed* to work; they only know how they *want* it to work. (Well, they probably have a clear idea of what the product is supposed to do for them. It's just that the devil's in the workflow.) To users of Dreamweaver or Visual Studio or XCode, anything that doesn't work as expected is a bug.
By Lori on
11/26/2008 4:19 PM
|
> 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.
Why? What's so funny about Jeff being right for a change? 'Perspective' being the key word here. To you, your definition based on the software specification is clear. The user, who in 99 % of the cases has never read the spec, couldn't care less. That is because for a developer, the distinction is important. I need to be able to determine the root cause of the incident, i.e. "what went wrong", in order to prevent it from happening again. For a user it isn't, he is more interested in having a software that works.
> 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.
No, you just should not let the bug/feature question dictate the priorities you are assigning to the issues. From a user's perspective, #791 is probably more important, because the software does not do what it sais it will do (inconsistent), while in #337 it just does not do it (consistent).
By Treb on
11/27/2008 9:24 AM
|
It's not always as obvious as you claim it is. Here's a real life example:
We have a Windows client, that implements a protocol according to a RFC. Customers requested one of our software products for the Mac to implement this protocol as well. We don't have the source code of the Windows client or any specs of it (it comes from a third party company, it is closed source, company refuses to tell us anything, not even if we are willing to sign a NDA). Okay, but we have the RFC, so we use this as a base for our client code.
Some time after we shipped the new version, one customer came along and said he has a problem: When using our client with one server (of course where exists a client exists a server, also closed source, etc.), our client fails. The Windows client works.
Interesting... we analyze the issue. We find out: The server violates the RFC. The RFC says a certain piece of information may be there only once in the package, but the server puts it there twice. Our client is not prepared for that to happen, so we fail parsing the package. The Windows client succeeds. The customer wants that our client succeeds just like the Windows client.
Some more background information: The RFC says "a parameter may appear only once within a package, unless the documentation of the parameter states otherwise". That means certain parameters may appear more than once. In case it may appear more than once, the RFC says "the client must concatenate the values of all instances of this parameter, as if the parameter was there only once". I don't see anywhere that the parameter in question may be there multiple times, so I interpret the multiple instances as a RFC violation - not our problem. The Windows client however seems to not care and concatenates the multiple instances as for parameters where multiple instances are allowed - this is also what the server seems to expect and both seem to work very well together.
*** Bug or Feature? ***
Was it in the specs? This is arguable. If we say that the specs were "implement a client that strictly follows the RFC", it was not. Thus it would be a feature. If the specs are "exactly copy the behavior of the Windows client", it was. Thus it would be a bug. In fact, the specs said neither. The specs were "Implement support for this protocol in our software", but nowhere was said if "this protocol" means to follow strictly the RFC or to implement it the way the Windows client has implemented it.
The easiest solution is to do nothing at all, inform the server vendor, tell him he violates the RFC and ask him to fix it. He will most likely, but this can be weeks to months and our customer is not happy, he wants it working now. We must fix it. Saying "it was not in the specs" is a poor approach. That we have to strictly follow the RFC was not in the specs either and we did it nonetheless. So we did something the customer hasn't asked us to do (because we thought this is the RIGHT thing to do) and now he can say "if you hadn't done that, it would be working; implementing a protocol also means you must be error tolerant towards poor server implementation". You can again argue about that; however, assume every web browser in the world would enforce the HTTP RFC to 100%, I think 33% of the WWW is offline tomorrow since so many webservers have so many tiny flaws (not critical, but not covered by any RFC).
For the customer, our software is not working as expected. If this is because we are too strict on the RFC or the server software is to relaxed on the RFC, so is the Windows client, this is nothing the customer cares for. He just wants it to work. And I doubt he will understand the decision to not fix it because we follow the RFC and the server should be fixed instead. He will run around in the web and tell everyone how bad our software is, not working with this server, and how great the Windows software works with this and every other server.
By Mecki on
12/2/2008 8:17 AM
|
Thanks for all the comments. However, they precisely illustrate the problem that Jeff was trying to address: poor product / project management. AFAIC the issues are crystal clear. I'll illustrate the examples, then explain:
@Lori writes "anything that doesn't work as expected is a bug". Correct. We created the expectation that something would work a certain way, and it does not. The failure may be one of poor requirements, documentation, or coding. Somehow, however, the customer received an expectation that a certain function would work a certain way and it doesn't. Bug. Easy.
@Treb writes that "Jeff is right for a change" but then goes on to state that to the developer, "the distinction [between feature and bug] is important." Jeff's point was that the distinction shouldn't be important... which would make Jeff wrong. @Treb then writes that to the user the distinction isn't important, because the user just wants software that works. Almost by definition, if the software doesn't work, there's a bug. Easy.
@Mecki is most illustrative of all. Forgive me for being rude, but Mecki, your kind of thinking is exactly what's wrong with so many developers. You write "The customer wants that our client succeeds just like the Windows client" then ask "feature or bug"? Bug, Mecki. Bug. The fact that the server violates the RFC is thoroughly irrelevant. Your customer doesn't want software that adheres to an RFC. Your customer wants software that works with the server as advertised. If, at the outset, you had decided not to support servers that don't adhere to the RFC, and had documented that, and advertised / warned your customers of that, then that's not a bug, it's a product design decision, and maybe a good one. But you didn't. The customer wanted something that worked with servers just like a Windows client, and you agreed to produce it, and you said you had, but you hadn't. That's a bug.
So you see, none of these examples are in the least bit questionable. In each case it is extraordinarily clear what the issues are. A competent product / project manager would quickly identify these issues as bugs and produce a development culture that understands why. And would communicate the issues clearly to customers, who would be delighted to learn that these issues are considered bugs and that the company would be attempting to resolve them in the next maintenance release for free.
By Rip Rowan on
12/2/2008 8:40 AM
|
Ok, sounds as if you disagree with Jeff only over semantics, not over content ;-)
Paraphrasing Jeff: "Do not care if it as bug or a feature request. See if it is a bad customer experience. If it is, fix it".
Paraphrasing you: "If it is a bad customer experience, it is a bug. Fix it."
Same end result...
By Treb on
12/4/2008 8:55 AM
|
@Treb - to say that it's just "semantics" misses the point that customers care that you acknowledge bugs. Or, in other words, to restate your comment:
Paraphrasing Jeff: "If it is a bad customer experience, fix it."
Paraphrasing me: "If it is a bad customer experience, acknowledge to the customer that it is a bug, and fix it."
This doesn't produce the same end result. True, in both cases the problem gets addressed. But by acknowledging to the customer that there is a bug, we validate the customer's input, and let them know that we acknowledge our errors. And by classifying these defects internally, we can practice better continuous improvement, and hopefully produce more defect-free software in the future.
Consider Jeff's example of the default font in Visual Studio. Suppose MS goes ahead and fixes the problem, and releases it as a new feature in accordance with the way they've classified it internally, and then sell it to us in the next version of the product. Will that produce the same customer satisfaction as calling it a bug, and fixing it for free? Even if it's only addressed in the next (paid) version, isn't there some kind of intrinsic value in listing it among the "defects fixed in version x" as opposed to the "new features in version x"?
I believe in "shining a bright light" on quality problems. There is intrinsic value in calling things what they are, and I think this case demonstrates the value.
By Rip Rowan on
12/4/2008 9:20 AM
|
|
|