

Why I don't use bug tracking software. - neiljohnson
http://fragile.org.uk/2010/04/why-i-dont-use-bug-tracking-software/

======
nostrademons
I'm a big fan of this approach, but I find that bugtracking is really useful
when you want to look back on the project and data-mine to identify problems
with your _process_ that you want to fix.

For example, if bugs get identified quickly and fixes mailed quickly, but the
fixes sit in code review for a long time, maybe it's time to lean on your code
reviewers a bit more. If 50% of your bugs are CSS regressions, maybe it's time
to invest in a CSS-testing framework. If most of your bugs are crashes caused
by memory corruption, you need to straighten out object ownership in your C++.

These kind of overall patterns are very hard to discern when you're
considering one bug at a time, yet fixing the root cause of them can lead to
big productivity gains.

------
warfangle
There's a major problem with completely ignoring and not tracking ignored
bugs:

They can come back and bite you. What may seem innocuous in one system now may
end up being a huge roadblock later on down the line when you want to
extend/modify/update said system with new features. While I understand that
some bugs are simply too minor and the edge cases simply too rare to bother
fixing, it's still a good idea to track them.

This also makes certain that they aren't brought up again as a new bug six
months down the line - you can point to the tracking software and say, "Yes.
We know about it, and it's not worth fixing."

~~~
nostrademons
Then you fix them later, when it _becomes_ a roadblock. At that point, you'll
have much more information about _why_ it's a roadblock and how you should
change things so that further development proceeds smoothly. And many bugs may
never become roadblocks at all (or may be obsoleted by other changes), so you
save all the development effort of fixing things speculatively.

I've seen a lot of time wasted trying to anticipate what might break later on
and bullet-proofing that, when the bullet-proofing simply breaks in new and
unforeseeable ways when you actually do try to extend it.

As for running across the same bug six months later - at that point, you
probably should reevaluate and decide again whether you want to fix it. The
"WONTFIX" designation was made on the basis of information that's now 6 months
out of date - the fact that the bug has come up to bite you again is perhaps a
good reason why now it should be fixed.

~~~
warfangle
Very true - all the more reason to keep track of it having been reported.

------
ww520
This ignores a critical use of bug tracking - communication. This approach
might work in a small local team, but falls apart in a bigger organization or
in a distributed environment. Bug tracking software is one place to store
information about the bug that multiple people can comment on. The person
discovering the bug might not be a developer, and often not. The person
testing the bug shouldn't be the developer; QA is doing it. If the fix
involves several people and they need to add input, they can add in their
comments in the bug tracking system. Cvs/Svn/Git can tie with the bug tracking
ticket to create a reverse lookup. There are so many benefits to have a bug
tracking system.

------
larsberg
"Hopefully such occurrences are rare and can be considered a special case."

What if it's both high-priority and hard? Like you find out that a fundamental
part of how your product works causes data to be miscalculated in a certain
scenario, and rewriting it while maintaining backward compatibility is a
multi-week task? During which you will get more high-priority bugs...

This article sounds like a fantastic sentiment, but even a small project of a
few hundred thousand lines will completely fall over as soon as it's released
into the wild. And if you had a medium-sized project you wouldn't even make it
past the point where internal testing is doing large scenario evaluation.

That said, if it works for your team, go for it. Never throw in more process
than you need, but don't assume that what works for small teams scales. Unless
you're trying to sell a book or consulting services, of course :-)

~~~
neiljohnson
"What if it's both high-priority and hard? Like you find out that a
fundamental part of how your product works causes data to be miscalculated in
a certain scenario, and rewriting it while maintaining backward compatibility
is a multi-week task? During which you will get more high-priority bugs..."

Perhaps it's a matter of terminology, if something is going to take a
significant block of time and have multiple people working on it then you need
some way of planning and tracking progress, your bug tracker may support
project planning as well (JIRA perhaps), but used a pure bug tracker will not
be as effective in fixing the problem.

"That said, if it works for your team, go for it. Never throw in more process
than you need, but don't assume that what works for small teams scales."

I fully agree with this sentiment, in this case we're talking about a dev team
of 6 working in a broader team of 50 developers. So I wouldn't describe it as
small, though there again if we were 250 developers then certainly, we'd need
more process.

~~~
alaithea
I'm not sure how much team size is relevant here. You're still creating
project history through a series of discussions and decisions, things that a
bug tracker can record quite well if used properly. Every team also has
turnover. Having your project's history recorded in written form can be
invaluable for new (and old) developers to research why something was done a
certain way, and not have to rely on memory and hearsay to do it.

------
inerte
It's a good strategy when you're doing small, quick, low impact releases. When
you have to coordinate with other areas of the company about when, and what to
release, or when the software becomes so large that there's a new bug every
day, then you need to keep a detailed track of the bugs.

------
hubb
i don't understand what this has to do with bug tracking software. you can
realize the same thing by placing all bugs in the tracker, and still ignoring
low-importance bugs.

at least that way when the bug re-surfaces, and you discover "its a bigger
deal than we thought", you'll know for sure that you've seen it before

~~~
roc
I can definitely see an argument for _logging_ ; particularly as relates to
project and developer metrics.

But 'Bug Tracking' is used to describe much more than 'Bug Logging'. Bug
tracking software packages define themselves and pitch their value based
_entirely_ on how they handle that 'everything else'.

Ergo, if you reject the 'everything else' (as the author does), you are
rejecting bug tracking software.

------
ErrantX
It's good to track low priority bugs; and specifically the customer they
affect.

In slow weeks (when we have little to do) we pull out the low-pri bugs and fix
them - then fire off a personal email to the relevant customer(s). It's
helpful in building an ongoing rapport with your clients.

~~~
swombat
You have slow weeks? In a start-up?

I'd consider that a very worrying sign.

~~~
chollida1
Everything is relative. In a startup a slow week might be like a really busy
week for a regular 9-5 job.

------
Deestan
It (obviously) works fine for small to medium projects, but I believe the bug
tracker-free approach doesn't scale at all. I don't know if the author thinks
it does or not, I just want to point it out to prevent people from getting
ideas. :)

Scenario 1: A salesperson or customer advocate reports five bugs found during
deployment of application X. Some of the bugs crosses several products, and
you have to "pass on" the bug to backend server developer Bob when you find
out your code is working as intended. How should you communicate the reported
bug and your analysis to Bob? Assign the bug to him in the tracker, and he
will get access to the complete bug history - initial report, discussion,
reproduction steps, analysis, why-this-isn't-a-problem-with-module-Q-even-
though-it-looks-like-it, new comments, screenshots, log files and
configuration file attachments from the customer. How will you (and Bob)
communicate progress to the salesman? He is CC-ed to each bug in the tracker.

Scenario 2: Your team is responsible for 4 products, which it switches between
focusing on every few weeks. When you're hard at work on releasing product A
version 3.1, and you spot a nasty and subtle problem with the design of the
message queue in the upcoming version 2.3 of product C. Immediately drop
development on A? No, you have a deadline to respect and the product C bug
isn't affecting anyone yet. Forget about the bug and _hope_ to rediscover it
or remember it (and 5 others) in 6 weeks time? That is irresponsible. You put
it in the bug tracker, and when product C time comes around, you look at the
bug database before starting work.

Or as larsberg says, when your project reaches a certain size and userbase,
you _will_ get several hard and timeconsuming bugs at the same time. You can't
always fixemrightaway or drop them.

------
mathewgj
A real benefit I have found in not tracking bugs is that the constraint makes
you much less cavalier about introducing complexity in the first place, which
is totally a good thing.

------
whyme
Assuming you have more work than resources (which is what one should plan for)
I would find it hard to sacrifice the 'strategy' aspect of bug tracking
systems. A good bug tracking system allows you to balance quick/low-overhead
logging with an ability to create categorical data points that let you analyze
your work & workload.

Having this data collection & reporting allows you to identify & trend problem
areas that can not be seen looking at a single bug at a time by different
people. It also allows you collect similar/overlapping areas of work to
strategically manage your resources and productivity - saving you time and
money.

Maybe the case is that the article comes from a company that's just too small
to realize the benefits of planning.

------
richardw
I add low-importance bugs that can be done quickly to a "quick" list. If I
have some time to spare, I check that list and knock off a couple.

Another idea is to simply try find out where a bug might be and add a TODO
comment to the file/class. This way, if someone changes that class later they
can keep the issue in mind.

------
bluesmoon
I often find bugs when I'm too bleary eyed to care about fixing them. If I
just go to bed at that time, I'll have forgotten about it in the morning.
Instead, filing a 2 line bug report serves as a good enough reminder for when
I wake up.

Also, what everyone else said :)

------
DenisM
When you bleed you need band-aid, but it's best not to bleed in the first
place.

Ideal situation is where you don't _need_ a bug tracker.

