Life Without Bug Tracking

It’s possible to create software without a bug tracker. You might even prefer it.

Many people think of issue tracking just like version control. You’d have to be crazy to develop software without a bug tracker. I used to feel this way, until I was encouraged to try something else. Now, I wouldn’t want to go back.

My first real experience with a bug tracking system was Apple’s Radar. It’s an incredible system in many ways. But, it also suffers from some serious problems. At the time, I was young and terribly foolish, and I thought many of these were related to the tool’s design. After Radar, I had the chance to use FogBugz, and then Jira. Both tools exhibited very similar downsides. Again, I blamed the tools themselves.

Looking back, I believe I was right to be unhappy with the tools, but I was completely wrong about the reasons. I can now recognize some of the problems I saw as systemic issues of bug tracking in general. Problems that are particularly bad when these tools are used as part of a project management system, which is common.

Kanban

My first real exposure to a non-issue-tracking-based workflow was during my time working at Crashlytics. The system used there was based around something called Kanban. A bug tracking database is really all about tracking work items. Kanban is also about tracking work items, but with much tighter constraints. If you’re interested in hearing more details about Crashlytics’ use of Kanban and how it fits into a larger process, you can check out this presentation.

At its core, Kanban is simply about visualizing work, and limiting your work in progress (WIP). Both parts are critical to its effectiveness. To give you a taste, I’m going to steal Kristen’s example from that talk because it’s excellent.

Think about a car factory. If something goes wrong at a stage of assembly, half-finished cars start backing up. Pretty quickly, all the work in the factory will grind to a halt until work can begin flowing through again. And, it’s completely obvious where the problem is. Software is no less sensitive to wasted work, delay, or bottlenecks, but it is far less visible. Your team does not see all the half-done features piling up around your desk.

Kanban helps to deal with the invisible aspects of software development. Visualizing work makes planning more intuitive and helps unfinished work (i.e. potential waste) stand out. Kanban can also really help with focus because of how it limits work in progress (WIP). I have found focus to be a vital part of building things, and I suspect that’s a common feeling. Additionally, limiting WIP keeps some reserve capacity on your team, so you can roll with the punches when surprise work shows up. It always does.

Another interesting thing about Kanban is that it doesn’t have to involve technology. Trello is a popular Kanban-like implementation, but a wall and some stickies can also work great.

What about Bug Reports?

Bug reports are a favorite topic of mine. If you rely on a bug tracker now, you’re probably wondering how you’ll track reports. The general approach is to take one of two actions. If it is critical, toss up a new item on the Kanban board. Because Kanban encourages you to avoid being 100% busy, you should have some capacity to deal with it.

If it is non-critical, you drop it.

I imagine a fair number of people’s blood pressure rising at this point. “You can’t just throw away bugs!”. “There could be critical info in there!”. “The customers! Think of the customers!”. And I hear you, loud and clear. I used to feel exactly the same way. And in principle, I agree. But, in practice, there is a cost to recording non-critical bug reports. A cost to you, and by extension, your customers as well.

Remember, you already have important feature work and critical bug fixes on your plate. Getting distracted and overburdened by additional, less important work is going to impact your customers more.

In theory, there is no difference between theory and practice. In practice, there is. — Yogi Berra

Weakness of Bug Tracking

Of course, all approaches have strengths and weaknesses. There is no magic formula for productivity. However, there are many things that can work against productivity. Traditional bug tracking has many of them. I’ll try to enumerate the big ones.

• Poor Communication: The number one reason I dislike issue tracking is the tendency towards poor communication. I’ve found written communication in bug tracking tools has a tendancy to degrade. Distracting coworkers isn’t good, but discouraging live communication is worse. Let alone getting confrontational in the stupid bug tracker.
• Distraction: The number two reason I dislike bug tracking is its negative effect on focus. When you are looking at a queue of work, things can catch your eye. Maybe you just want to spend the afternoon looking at that crazy bug report from last week. That constant temptation to try to drive the ever-increasing queue to zero is as honorable as it is distracting.
• Stale Bugs: An obvious issue with bug databases is obsolete bugs. Modules get rewritten or removed all the time. It often seems like an easy exercise to clear out the related issues. But, there often are issues on the books whose connections are non-obvious. These just become baggage the team carries, and can easily result in wasted work.
• Sunk Cost: A great strength of bug tracking is keeping a record of debugging efforts. But, this can easily become a real weakness. Bug histories can get very long, especially as they change hands. The more effort that’s been put in, the harder it is to let go. This compounds with the stale bug problem.
• Activity vs Progress: I’ve come to really appreciate the distinction between activity and progress. Keeping busy isn’t at all the same thing as moving towards a goal. Bug tracking can make the goal seem like zero bugs, which is rarely an organization’s actual main objective.
• Project Management: It is very common to combine bug tracking with project management. This can further muddle the activity/progress relationship. And, the tendency towards poor communication can really spell trouble for team dynamics.

Weakness of Kanban

Nothing’s perfect, of course. While Kanban can address some of the problems listed above, it also has its own set of disadvantages. After using it for 5 years, here are the areas I’ve struggled with the most.

• Source of Work: New work items still need to come from somewhere. They could come from QA, a team meeting, customer support, or a larger project plan. But, it tends to be unstructured, and can end up just being the loudest voices.
• Long-Term Projects: A Kanban system often incorporates a time window. A way to see what the team is working on this week, for example. This can make larger projects more unwieldy to manage. Breaking up big tasks into smaller chunks is natural, but the big picture can sometimes get lost when there is too much focus on fixed-sized tasks in small time windows.
• Complex Boards: Kanban is simple, at first. But, teams often opt to use colors, shapes, or columns to add more structure and meaning. These can be a source of confusion, friction, and a barrier for new teammates.
• Buy-In: Like any process, Kanban is not for everyone. Some people just want a prioritized list of tasks. Any process with poor buy-in can be a real problem for a team, so this is definitely something to watch for.

Welcome Experimentation

For many software projects, I think pure Kanban with little-to-no bug tracking of any kind is a great option. I have found both my motivation and focus to be positively affected every time there’s been a “purge” in the tracking system. And when you remove the tracking system altogether, the effect really does last. I’ve done it on three separate occasions, and the fallout has always been much less than I feared. But, it has not always been zero. Occasionally, yes, bugs are forgotten or neglected.

And when a critical bug does get rediscovered, you just toss up a task on the Kanban board ;)

I’ve been consistently surprised at how strong an emotional reaction I have to changes in work process. Even for relatively small things, I’ve often initially been resistant. But, I’ve also been equally surprised at how much better things ended up being once the dust settled. Turns out that keeping an open mind can be a good idea, especially when you haven’t tried an alternative.

Ditch your bug tracker, and give Kanban a shot. I bet you’ll like it.