Coding Horror: That's Not a Bug, It's a Feature Request | Hacker News Reader

Coding Horror: That's Not a Bug, It's a Feature Request

codinghorror.com

23 pointstwampss19 comments

Ah, come on, it's not that hard.

A bug is something that should be working according to the specification (or, if the specification is missing, according to common sense), but is not working. If you have a button labelled "print" and it doesn't print, that's not a feature request, it's a bug.

Feature requests are made up of enhancements and requirements.

An enhancement is an small, incremental and obvious improvement to an existing function/element that doesn't change the fundamental functioning of that function/element. If the print button is there and is working fine according to the spec but a user requests that it also prints the date at the top of the document, that's an enhancement.

A requirement is a wholly new piece of functionality that didn't exist before. If the print button is there, and it works fine, and the user requests that it should allow the user to select which pages to print before actually printing, that's a new requirement.

It's really not rocket science...

And before people down-mod me because I forgot to mention it, the reason why Jeff is perceiving that something is horribly broken there is not because there's a problem with classifying what kind of "request" the user made. If your developers are in the habit of ignoring feature requests because they're not bugs, you need either new developers or a new project manager.

"Work items" (whatever kind they are) should be implemented based on the value they add to the product, the company, the customers, etc. Bugs can be minor and requirements can be critical.

In the case Jeff discusses, yes, it's a bug, because it should match the requirements, which presumably include providing customers with the tools to build quality Windows applications. Is it a critical bug? Depends on the point of view. From a developer point of view it's not critical, and they are right to ignore it from that narrow perspective. "Critical bug", in developer-speak, means "The sky will fall when someone clicks that button". However, it should be critical to the windows UI guidelines team and they should be the stakeholder pushing to get it implemented, on the basis that it makes them look like dunces.

So the problem there is not about what you call the bug, it's about the fact that the windows UI guidelines team don't care enough (a fact more than obvious whenever I stare at a vista screenshot).

"Bugs can be minor and requirements can be critical"

Exactly, however "Feature requests" are always considered optional and "Bugs" are always pushed through triage. This distinction causes moderately important feature requests to be ignored while moderately important bugs are fixed.

Jeff's point is that the distinction between bugs and feature requests has the unintended consequence of weakening the sorted order of the priorities of this middle range of work items. Additionally, I would argue that identifying something as a either a bug or feature request doesn't provide any value. Spend that energy identifying customer impact.

If it doesn't provide any value and actually requires some effort, stop doing it.

You presume that your requirements are complete and known. Often the reason that something like the font issue Jeff talks about happens is that there is no spec. Is it a bug or a feature if the spec doesn't mention the question? In theory, "bugs are when behavior doesn't match spec" is an easy rule to apply, but in practice it's often not obvious what the spec is.

If there is no spec about it, it's a requirement. But requirements are no less important than bugs. The concept that "new requirements are extra and therefore should be discounted" is a fallacy of the outsourcing model. New requirements often point out things that were missed from the initial requirements gathering, and in many ways are more critical than most bugs.

I work in a contract environment, and it's in our mandate to avoid feature creep. Enhancements have to be derived from the requirements and design that the customer bought off on, or we require more money. Bugs that interfere with our commitments to the customer, on the other hand, are handled with extreme prejudice.

MS is in a different situation really because they have no contractual obligations. Nobody is really pushing against their products for quality, so their upgrades are driven by marketability or something.

The irony is that quality is the best marketing. The product that aims at marketability at the expense of quality will achieve neither, the product that aims at quality at the expense of marketing will achieve both.

My employer (who works in a highly regulated industry) works the same way. If a core product must be modified, we issue a change control memo. The items in the memo either have to be tied to bugs in our bug-base or, in the case of enhancements, a specification.

Because of the high volume of paperwork that surrounds software releases (specifications, documentation, test matrices, test reports), enhancements are typically put into a stack until there are enough to justify the load of paperwork that must accompany such a release. Bug fixes still require paperwork, but specs don't need to be written, only test reports.

My sympathies. We don't have as much overhead involved, but around integration time, it gets a lot like you're describing. We get away with a lot of common sense at other times.

More often, our enhancements get rolled into a new contract. If they are peripheral enough, we might not even do requirements for the new contract. Just using the old change requests is as specific as it gets.

It's actually not as bad as it sounds. Devs produce only a small amount of documentation (including unit test reports)--it's the product manager and QC department that really have the burden of documentation. It's nice having a well-defined set of requirements, and because of the overhead of updating documentation, scope creep is kept to a minimum.

>The irony is that quality is the best marketing. The product that aims at marketability at the expense of quality will achieve neither, the product that aims at quality at the expense of marketing will achieve both.

It'd be nice if it'd be true. But look no further than the example at hand and its relatives.

Discussions about the meaning of words, while sometimes fun, only rarely produce any useful results. Generally it is better to choose some precise definition in your context, and see what you can build from that / where does that take you.

This whole post is such a disguised discussion. He never picks a precise definition of "bug" or "feature request". If he did, it would be immediately obvious were each case lies - but then it would be also obvious the post is content-free...

At any case, it would be nice if there was some way of telling HackerNews "I don't want to see any posts coming from codinghorror"...

I think the point is exactly that these precise definitions should just be thrown out. The goal is to make something people want (or, at least, that they will pay for). Making distinctions about where bugs come from, who reports them, when in the cycle you found them, etc. are all part of most development processes, but they are masking the issue.

Make your software do the right thing.

I agree. I remember the days when hacking was all about windows and desktop apps, but times have changed.

I am not a windows programmer. Question: Do those property sheets support setting the font to any sort of variable or expression? Does it support making that variable or expression the default for that application?

If not, that's the real problem. Anything where you have to change every property setting manually to get a new font is a non-starter, IMHO.

Although I do agree bugs may be pushed to the vast abyss of feature requests or "enhancements," the answer is pretty simple:

In the waterfall model, if it isn't in the requirements/specifications doc, it isn't a bug. It's put in as feature request and if you're lucky maybe some day years later it will be addressed in a redesign project or a "phase 2", but most of the time it will never happen.

In agile, if it's not a story, you put it in the backlog and it will eventually make it into an iteration. For example, as testers, we bring it up to the PM/PO so that he can write a story for it. They'll prioritize and put it in an iteration because the developer will not do anything about it unless it's a story and his time accounted for it.

This ties nicely into the "Five Whys" series that came through here.

Why is this VS customer pissed? Because VS uses a default font that doesn't match the system theme.

Why is that font used? Because it's always been that way? Or did the VS team change it around the time Vista was released?

Why didn't the default font change to match the new OS theme? Lack of communication? Did the VS team disagree with the HIG team at Microsoft while Vista was under develoment? While we're at it, why doesn't the application just take the window manager's default fonts unless specified otherwise?

This would be an interesting rabbit hole to follow down if I cared about Visual Studio and Windows development.

If you use a product made by a company that can't manage to fix something like that over the course of 4 years ("fix" because it goes against their own guidelines) you probably deserve to have all your fonts look like shit.

Just sayin'.

I like the way this was prefixed. "Coding Horror:" ...works for me.

Why not have a slider from +5 Bug (red) to +5 Feature request (green) through 0 (grey or yellow)?

Reply on news.ycombinator.com