I recently read "Why programs fail, a guide to systematic debugging" by Andreas Zeller. Experienced programmers will find an easy read of their day-to-day activities described in much details. This makes it a valuable book to recommend to anyone that manages technology projects but who might not have a strong programming background. Chapter two in particular will definitely appeal to people having to manage problems as opposed to directly solving them. My thoughts on the subject are captured in this note.

Pretty early on in a project, experienced developers will set up an source control repository. It is usually much later on that an issue tracking system shows up, usually under the pressure of management. It is not by accident. At that point it is becoming increasingly necessary to clean-up the mess, get the process under control and deliver on promises to customers.

So an issue, defect or bug tracking system is brought up. The application crashes under a specific test case? Easy, put it in the issue tracking system. A build issue? Put it in the issue tracking system. A question about installation procedures? Put it in the issue tracking system. A new feature request? Put it in the issue tracking system. There is a question about installation procedure? Put it in the issue tracking system. Things seem to improve for a while but after a few weeks the issue tracker contains a huge collection of random things. It is becoming a mess to sort out the ones that need to be done, the ones that should be delayed, the ones that are duplicates and the ones that are purely bogus. It is time for the first bug scrum.

Should we use an issue tracking system?

As many times before, we though introducing a new tool will solve all our problems, magically. As many times before, we are faced with reality. It cannot. Time to remember the basic scientific method of project management.

• 1. Which questions we are trying to answer?
• 2. Which paradigms can effectively be used to answer those questions?
• 3. What tools best implement those paradigms?

First and foremost, which questions are we trying to answer? Spending time defining the problem is often overlooked, though in practice, it is the secret of the best project managers I have ever met. It might seem easy and obvious: Deliver the best quality product on time on budget. How is quality defined? Is it reliable? fastest? When I have to trade off between quality, time and budget, what are their relative priorities? How does it all translate into useful practical questions I can use to manage the project day-in day-out? Those questions seem far away from issue tracking methodology but they do frame the mindset in which technical solutions are evaluated so it is good to start there.

Now we are the point in the project where obviously we need to clean-up the mess. Why? Is the main problem that the delivery date is slipping? Is it that we do not seem to be able to get rid of those unexpected crashes? Are customers complaining they do not see progress on their reports and answers to their questions? An issue tracking system might not be appropriate in all those situations.

If the delivery date is slipping, we might not have estimated correctly the cost of development of specific features. We might not have tracked the dependencies between development teams accurately. Will an issue tracking system solve those problems? Would it not be more appropriate to use a project schedule tool and GANTT charts?

The application crashes. Bugs are fixed. The application passes the test case but start crashing under different conditions. Bugs are fixed. The initial test case crashes the application again. We seem to be running in a loop unable to move forward and it takes a huge amount of resources to do the testing. Will an issue tracking system solve those problems? Would it more appropriate to introduce test automation? Mechanical generation of test cases?

Our customers love our product (Yes, they do!) and are willing to help make it better but complain they do not see their reports acted upon. They have a legitimate requirement to base their business on when specific bugs will be fixed and on when specific features will be introduced. They are frustrated we do not communicate either. Will an issue tracking system solve those problems? Potentially. It seems like a great opportunity to track every request as well as introduce more transparency of our project schedule.

What issues do we track?

At some point we will have a lot more customers so it seems just a matter of when we will use an issue tracking system then. What are we using the issue tracking system for though? Bug reports? Obviously. Obviously? Should we create a tickets for

• questions about the product?
• new features and future development?
• bugs found in the course of writing code?

Most issue tracking systems are implemented on top of a relational database. It is arguable if that is the best approach in all cases. For example fortylines tracks issues as "todo" items stored as e-mail threads alongside source code and documentation following fortylines development philosophy. This enables contributors to easily cross-reference source code, todo items and documentation and let the semilla web-application presents those cross-references as HTML hyperlinks.

Fortylines chose to associate very little, straightforward to enter, information with each todo items. It might not be enough for everyone. What information do you need to associate with each report?

• The reporter name?
• The version number the bug was reported against?
• The version a fix is targeted for?
• The sub-component(s) where the bug lies inside?
• The contributor responsible to investigate the report?
• The commits in the source repository related to the report?

This list is neither exhaustive nor... maybe relevant. That is right. If you are working on a live web-application using a feature-by-feature roll out schedule, it might be more effective to track

• What page with that bug did get served?
• How many people did the bug affect?
• How long was the bug "online"?
• When a fix will be available?

Conclusion

An issue tracking system is not always the most appropriate solution to get a project under control. When we implement solutions around an issue tracking tool, it is not straightforward to decide what should be tracked and how. In all cases, choices need to be carefully balanced and a consistent approach to the entire project development process need to implemented. That is where fortylines tools and expertise might come handy. Please, feel free to contact us. We will be happy to help your organization be more efficient, yet taking great of your specific constraints.