From rssfeeds@jmason.org Thu Sep 26 16:34:02 2002
Return-Path: <rssfeeds@spamassassin.taint.org>
Delivered-To: yyyy@localhost.spamassassin.taint.org
Received: from localhost (jalapeno [127.0.0.1])
by jmason.org (Postfix) with ESMTP id 6664D16F18
for <jm@localhost>; Thu, 26 Sep 2002 16:34:00 +0100 (IST)
Received: from jalapeno [127.0.0.1]
by localhost with IMAP (fetchmail-5.9.0)
for jm@localhost (single-drop); Thu, 26 Sep 2002 16:34:00 +0100 (IST)
Received: from dogma.slashnull.org (localhost [127.0.0.1]) by
dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id g8QFSTg24435 for
<jm@jmason.org>; Thu, 26 Sep 2002 16:28:29 +0100
Message-Id: <200209261528.g8QFSTg24435@dogma.slashnull.org>
To: yyyy@spamassassin.taint.org
From: joelonsoftware <rssfeeds@spamassassin.taint.org>
Subject: We're trying to decide if FogBUGZ 3.0 should support custom
fields. Histor
Date: Thu, 26 Sep 2002 15:28:28 -0000
Content-Type: text/plain; encoding=utf-8
URL: http://www.joelonsoftware.com/news/20020912.html
Date: Not supplied
We're trying to decide if FogBUGZ[1] 3.0 should support custom fields.
Historically, I am opposed to custom fields in principle, because they get
abused. People add so many fields to their bug databases to capture everything
they think might be important that entering a bug is like applying to Harvard.
End result: people don't enter bugs, which is much, much worse than not
capturing all that information. You can always "page fault" to get the
information if the original report forgot it. Rather than having a field in
every bug where you enter the version numbers of every DLL on your machine
(this is an actual customer request), information which is likely to be
relevant only for a tiny percentage of bugs, why not just have the
programmer-assignee look at the bug first, and if they think it might be
dll-version-related, only _then_ bounce the bug back to the originator asking
for the DLL info? Similarly, it's always tempting to add a field in which you
ask for the OS version in which the bug occurred. This sounds logical, but
trust me: adding fields like this is guaranteed to do one thing and one thing
only: reduce the number of bug reports that get into the system in the first
place. Only a small percentage of bugs are really OS dependant and you can
always include that info in the text description of the bug if it happens to be
relevant. (But then how do you search for, say, all bugs which only happen on
Windows 98SE? Aha! You can't. Ever. Even with the custom field. Because not
every bug has been regressed on every version of every operating system, so
this search doesn't make sense in the first place. The info wasn't captured. Do
a full text search for 98SE and you'll find some of them. Life is imperfect.)
Life would be more perfect if every bug report included megabytes of
information -- a complete dump of every byte on the hard drive and in RAM on
the computer in question and while you're at it, a photograph of the tester's
workspace. But the goal of a bug tracking database is to _keep track of bugs_,
which, all else being equal, takes priority over making it easy to find them. I
have heard countless stories of development teams where the bug tracking
package was so high-ceremony that people were afraid to enter bugs in the
system, because they didn't know what all those fields were. The _real_
bug-"tracking" happened in email, post-its, and hallway conversations. Great.
A pretty common question we get on the customer service line is, "does
FogBUGZ support custom fields?" Rather than giving our usual answer ("no. on
purpose.") over the last few weeks I've been saying, "can you please tell me
what fields you would need? We're trying to decide whether to implement that
feature in 3.0 and we want to know why people need it." The interesting thing
is, almost all of the fields people ask for _are already in FogBUGZ,_ and the
other ones, in my educated opinion, shouldn't be fields. And in fact, our
existing customers are certainly happy without custom fields. One of our
biggest site licenses was sold to a semiconductor company, and I myself wanted
to add a custom field for them to keep track of versions of the circuit design,
but I didn't, and they never needed it (even though they had been keeping track
of it with the old bug tracking package which had custom fields), and they are
happy and keep buying more site licenses.
But the dilemma for us is that many customers are evaluating bug tracking
software and they consider the lack of custom fields to be a major weakness in
our product. "Gosh, even Filemaker has custom fields." Righto. It's true. And
who am I to tell my customers they are wrong? One person who I was talking to
yesterday would have used a custom field for something that we already have a
built-in field for. This would have made their database confusing and
inconsistent and would have definitely caused more problems than it solved. But
it's still rude of me to tell customers that we don't have that feature _for
their own good_, even though it usually is, and we're losing some sales because
of it.
Sigh. I guess we could have a custom fields feature but hide it and make it so
hard to use that people don't use it. At least we won't lose any sales :)
[1] http://www.fogcreek.com/FogBUGZ