On Hacker News, uuilly tells how they implemented a simple bugtracking scheme using DropBox, see Using Dropbox to Track Bugs. I don't know if I should smile because this is a nice example of how to find a simple and pragmatic solution to some problem you have. Or if I should cry over all the bugs they are now going to track instead of fixing them, see Why Bugs should not be Tracked.

By Lars Thorup

Wednesday we visited NEC and Change Vision, both located in Tokyo. At those visits we got the chance to see one of the major Japanese corporations in the IT industry, as well a small software company.



We started out the day by visiting Change Vision, a company founded by Japanese author Kenji Hiranabe. We got a presentation of the two products of the company, JUDE and TRICHORD. Both seemed to be built on the idea of "mieruka" (making visible), which is a concept used by Japanese organizations for sharing information by making it visible in an easily understandable form.

While noticing the extensive use of simple visuals for tasks, metrics, ideas, releases and retrospectives, I have to admit what personally struck me the most was the bug-tracking system of Change Vision. It was visualized using LEGO bricks in a constrained physical space. This provides kanban-like control of the "bugs in process", by showing not only the variation in complexity of bugs, but also making it easy for everyone to see when you are running out of "slots" for new bugs, and thus have to start fixing some. Personally I just can't wait to try this visualization idea back home.

Judging by the discussions that took place after the visit, I think we all got a lot of inspiration from visiting a truly agile environment.

Later the same day we visited NEC for a techical presentation as well as a presentation focused on their development process. During the visit we learned that NEC had experimented with using Toyota Production System (TPS) a.k.a. Lean in the development process, for instance with the use of a kanban system to control the workload between different parts of the organisaion. Most surprisingly the system was put into place for controlling hand-offs between design, code, and test-phases. I think that as a group of agile thinkers, we were a bit stunned by this implementation.

NEC had also experimented with the TPS "stop-the-line" practice, in their development process, but had abandoned it due to inefficiency. Unfortunately we did not get a chance to hear the reasons that led to this conclusion.

(BestBrains getting a demonstration of Japanese innovation. This is an NEC electronic whiteboard with a built-in printer!)

By Sune Gynthersen

Reading Lars' article Why Bugs should not be Tracked, and the following discussion on Joel on Software made me think quite a bit about my own view on bug tracking.

Most people in the software industry would probably agree that bugs are inevitable. But consider this -- If the rate at which bugs go into your bug tracking system is higher than the rate at which you are fixing them, you are inevitably up for trouble.

You can either prioritize the same bugs over and over, or close them with a "Won't fix" right away. Prioritizing the same bugs over and over doesn't seem to make much sense for something you are unlikely to fix, as long as the rate of incomming defects is not decreasing.

I am not saying there is something wrong with the bug tracking systems. What is wrong is that we have so many bugs that we need systems to track them and (re)priotize them. The reason I'm quite skeptical about tracking systems is because using them takes away focus from the underlying issue.

Reading the discussion on Joel, it seems that there are those who believe that the human race would not survive without bug tracking systems.

"I have 20 bugs comming in every week -- I need a bug tracking system!". Yes, then you certainly do. At least until you bring the defect rate down to 1 bug a week. You may feel you are in need of a bug tracking system, but what I think you really need is to ask yourself: Why are we releasing so many defects?

I like to tell myself that everytime a bug is found outside our lab, my team is responsible for wasting the customer's time.

If you have a lot of existing defects in your bug tracking system consider the following experiment:

Say you have 300 open bugs in your tracking system. You estimate that 200 of them can be considered important to your customers. How long with it take to fix these issues if you didn't work on anyhing else? Let's say 3 months. Now remove the 100 you won't fix anyway (They will show up later if they really are important)

Use a bug tracking system for the next 4 months only. This gives you 3 months to get the number of defects down to zero, as well as 1 month figure out how to get your defect rate down to one per week. If you can manage to do so your need of a tracking system should have changed.

I believe that if you can...

1. Reduce the rate at which you introduce bugs.
2. Choose to either fix or ignore the legacy bugs you already have.

...You will waste less time on "tracking" bugs, and in time your bug tracking system should become more or less superfluous.

By Sune Gynthersen