The Joel on Software Discussion Group (CLOSED)

http://www.jamesshore.com/Agile-Book/no_bug_database.html

Does this mean the end of FogBugz? :-P

To be honest, on projects where I am the only programmer, my "bug" database is filled with to-dos and feature requests, but VERY FEW bugs.  If the bug requires system wide changes (yikes) then it's in the system, otherwise, I just fix the little problem, record it as done, and move on.

Our folks in India get really tired of flying over here to take a look at the bug index cards.

Let's throw out our bug database and instead replace it with this other method of tracking exactly the same thing, but it's XP and cool!

They still have a list of bugs that need to be fixed, however, now you've lumped it with everything else in the cool new 'xp fad' way of doing it, rather than using the medival notion of some bug database!

Bug database is so 1990s.

Try defects database.

Silly. Just have the admin assistant fax the bug cards overseas every afternoon.

I wonder if this idea would raise fewer hackles if we came at it from a different direction:

Bugs are bad. Therefore, having as few bugs as possible in your released software is good.

Bug tracking software is useful when informal means of defect or feature-request tracking do not suffice. Typically, this happens when there are many bugs.

Therefore, setting up a formal bug tracking system is an admission of failure: there are too many bugs. Setting one up at the beginning of a project is even worse: it denies even the hope of success.

Therefore, a software project should only set up a bug tracking system after the need is demonstrated, and should strive to avoid that need forever by minimizing the number of bugs shipped, and keeping the number of bugs open at any one time very close to zero.


Now, my attempt at a less emotional question: in what way does your real world differ from the ideal I've presented? Can it be fixed?

One advantage is that we can keep a track record of the bugs, the sources, who fixed the bug, etc.

Not sure whether this will make people more sloppy.

> Therefore, setting up a formal bug tracking system is an admission of failure

So are insurance, seat belts, at damn near everything else inlife. Failure happens. The no bugdb model makes so many simplifying assumptions about the organization as to be nothing but a joke.

If your support is in North Dakota and you are in India, what happens when they want to file a bug report from a customer? That would go where exactly?

So what do you do when you have 20 defects of the class  "the text looks a little fuzzy in Times Roman" and only 3 of the class "pressing <enter> on this screen corrupts the database" and you need to release in 1 week? Which ones do you throw your 3 best developers at? Which ones do you assign to the new grad?

You can't just say you'll fix bugs as they arise, because they have a way of showing up faster than they can be squashed. At some point you have to admit that you need a real defect-tracking system and you need to triage the defects to fix the most important ones first. If cards and card catalogs do it for you, fine. Most sane people will use some form of computer database.

Mark,

And then you lose out on all the historical data of any bugs that are opened up because you're not storing them anywhere but on little cards.

Unless of course, you're logging them in a database somewhere or filing the cards into folders.

But then you've got a database... with bugs in it... a bug database, and we're back to step one.

Unless you can claim that your software never has any more than 1 bug in it at a time, in which case you're just pompous.

I read through the article a second time just now.  It strikes me as utterly silly, consisting of semantic games instead of real suggestions.  The real problem isn't the bug database; the real problem is the sheer number of bugs.

Extreme Programming may be a solution to that problem, or it may not.  But it's not a matter of getting rid of the bug database.  Rather, it's a matter of implementing such a high-quality development process that you almost feel silly having bought a bug-tracking product because there are always so few open bugs in it.  Even then, as others have pointed out, the bug database has historical value, whereas a stack of index cards will most likely get thrown out in the next office cleaning.

I knew there were holes in my arguement, but the ones that have been brought up were not the ones I expected. Cool. I'll work on a more complete response later, when I've recovered from my own personal celebration of Friday, and Labor Day Weekend.


In the meantime, why the focus on attacking "cards"? The ideal world I tried to present surely sees index cards as a bug database--just another reaction to having too many bugs to deal with with an informal system.

I never defined "informal", of course--I think I meant "entirely inside the heads of the developers".

> think I meant "entirely inside the heads of the developers

How would I attach a core dump and several MB of log files to your brain?

Hi, everybody--thanks for your comments on our upcoming book.  Although the comments so far have been pretty negative, I'm actually happy to see them.  You see, we (chromatic and I) are writing this book for people who have heard of agile software development, are interested in learning more, and have a healthy skepticism about agile development.

That's not to say that we're going to try to convince you to use agile development.  Actually, I have no interest in convincing you to do anything.  I figure that if assume our audience is intelligent and capable, and we clearly lay out what we do, why we do it, and when we think it's inappropriate, then you can figure out for yourselves what you want to do.

So I'm not about to argue for the idea of "no bug database."  I'm learning, however, that there are some ideas that we didn't communicate well.  (The biggest one is that our main point--"fix the bug now if you're going to fix it at all"--gets drowned out by the title.)

At any rate, the main reason I dropped in is to invite you to review and comment on the rest of the book.  Like I said, the skeptical (but interested) reader is our target audience.  We'd love to have your feedback.

The book is titled _The Art of Agile Development_ and it's available for review at:

http://www.jamesshore.com/Agile-Book

We have a Yahoo discussion group set up for review comments.  It's the "art-of-agile" mailing list and there's a link to it on the page mentioned above.

Regards,
Jim Shore

"So I'm not about to argue for the idea of "no bug database."  I'm learning, however, that there are some ideas that we didn't communicate well.  (The biggest one is that our main point--"fix the bug now if you're going to fix it at all"--gets drowned out by the title.)"

I thought that point was communicated relatively well; I disagree, but I understood the point.

In my experience, to fix a bug or not is rarely a binary decision, but rather is more an ordering decision, and the exact same sort of ordering decision any other feature would have -- any time spent fixing a bug is time not spent implementing a feature for this iteration, so the bugs have to be ordered by priority, and balanced against the utility of the features you'd like in the next iteration.

An absolute fix it now or don't fix it at all policy seems to me to be contrary to the agile methodology which, from my understanding anyways, is about ordering features based on priority, and iteratively providing more and more features. Why are bugs and exception to this? Is not the lack of a problem in the software a feature?

Brian, that's a good point about the subtlety of bugs.  One point we tried to bring out in this chapter is that there's a point at which it's clear that only the customer can prioritize a bug fix, in which case you should create a story for it.  Perhaps it's better to restate Jim's phrasing of our rule as "Fix or schedule bugs immediately instead of filing them."

It's difficult to invent a punchy phrase around that, however.

> fix the bug now if you're going to fix it at all

Fredrina in Idaho filed a bug last night. Should we jump on that or should we work on our next story in the sprint? Hmm.

Perhaps simple rules that only work in simple contexts yet are generalized for everyone are the problem.

"Fredrina in Idaho filed a bug last night. Should we jump on that or should we work on our next story in the sprint? Hmm."

Just for the purpose of discussion: Assuming you're going to fix Fredrina's bug, what's the difference between fixing bugs when you find them and batching them up to fix at the end of the project? You have to fix those bugs eventually, and it's cheaper to fix bugs sooner, so why wait?

Cheers,
Jim

> Assuming you're going to fix Fredrina's bug

Big assumption. The bug may be a duplicate. It takes resources just to figure that out. Or the customer may think it's not worth fixing.

>what's the difference between fixing bugs when you
> find them and batching them up to fix at the end
> of the project?

Products never end so there is no end at which to fix all the bugs.

And let's say you are using Scrum and you have a sprint running. When a bug comes in do you stop the sprint? Or do you put the bug in the backlog to be scheduled?

It's a complicated issue with a lot of factors. Certainly more complex then just drop what ever you are doing and fix Fredrina's bug.

Can you imagine how many bug reports Turbotax gets? If the engineers were to handle every bug in the manner you suggest they would never work on the product.

> You have to fix those bugs eventually

Uh, no you don't. A minor bug happens in windows 95 and we have only 5 customers on that platform. Would it be rational to devote resources to fixing that bug when we can work on revenue enhacing features?

There's a certain lack of strategic vision here in thinking about bugs. Every bug fix is an investment that must be prioritized with all other work to see if the payoff is large enough to both do and do ahead of other work.

Son of parnas, I agree with everything you're saying.  I note, however, that in your eagerness to call us idiots, you have not noticed the parallels between your words and ours.

Cheers,
Jim

> that in your eagerness to call us idiots

The only use of the word idiot in this thread is in your post.

Son of parnas:

Silly me--when I read phrases like "...nothing but a joke," "simple rules that only work in simple contexts," and "There's a certain lack of strategic thinking here," I interpreted you as saying, "You, sir, are a blithering idiot."

I don't know how I could have made such a terrible mistake.  My apologies.

Cheers,
Jim

> My apologies.

Accepted.

> nothing but a joke

That was a little over the top.

> simple rules that only work in simple contexts

And that's absolutely correct, as you have agreed.

If you publish stuff telling everyone your truths you can't get all touchy when people disagree. And when you boil down a sophisticated subject a simple yet wrong rule you can't be surprised when people call you on it.