

Coding Horror: That's Not a Bug, It's a Feature Request - twampss
http://www.codinghorror.com/blog/archives/001189.html

======
swombat
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...

~~~
swombat
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).

~~~
snprbob86
"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.

------
msg
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.

~~~
bmj
_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._

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.

~~~
msg
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.

~~~
bmj
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.

------
igorhvr
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"...

~~~
bestes
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.

------
jerf
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.

------
felideon
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.

------
etal
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.

------
tdavis
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'.

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

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

