9

I don't like issue tracking systems because:

  • It takes too much time to describe issues in it. This discourage its usage.
  • You create a place to keep your bugs. And if there is a place for them, people usually don't care too much about fixing a bug cause they can put it there so that someday someone can fix it (or not).
  • With time, the bug lists gets so long that nobody can deal with it anymore, taking up a lot of our time.

I prefer handling issues using post-its on a white board, face-to-face conversations and killing important bugs as soon as they appear. I don't care too much to keep track of bug history because I don't think that it is worth the overhead.

Am I alone here? Are there studies (book/article/whatever) about the disadvantages (or great advantages) of using issue tracking systems?

Improve this question
8
  • 5
    Voting to close, too localized. The problem here does not appear to be with issue tracking systems, rather with the bug-handling process at the company.
    – P.Brian.Mackey
    Nov 23, 2011 at 18:10
  • 1
    What issue-tracking systems have you tried (other than post-it notes and whiteboards)? What was the process around their usage?
    – FrustratedWithFormsDesigner
    Nov 23, 2011 at 18:29
  • 1
    Of those, I've only used Jira (I do agree that it seems to have a lot of overhead, until you get used to its "rhythm"). Not a fan of the web UI, but it gets the job done. Here, we also use MKS, which also does source-control. It's better than Jira. None of them are perfect, but they're all still better than paper notes and people's falliable organic memories.
    – FrustratedWithFormsDesigner
    Nov 23, 2011 at 18:40
  • 15
    I guess I'm confused by the question. Using post-its on a whiteboard IS an issue tracking system. If your project/team/code base is small enough and post-its + face to face works, you probably would have a tough time convincing yourself to add more overhead to the process. There are plenty of down sides to using a system like that, as noted below. As soon as the project and team grows, especially when team members might not be in the same building, city, or country, other systems begin to shine as noted in the answers below.
    – s_hewitt
    Nov 23, 2011 at 20:12
  • 2
    how do you attach a stack trace to a post it? or a screenshot? or an error message?
    – jk.
    Nov 24, 2011 at 8:29

5 Answers 5

Reset to default
41

It takes too much time to describe issues in it. This discourage its usage.

If you can't even describe a bug how can you begin fix it?

You create a place to keep your bugs. And if there is a place for them, people usually don't care too much about fixing a bug cause they can put it there so that someday someone can fix it (or not).

That is a problem with your team not with the software.

With time, the bug lists gets so long that nobody can deal with it anymore, taking a lot of our time.

Again your describing a problem with your team.

The point of bug tracking software is not to help you motivate your team to fix bugs, it's to keep a record so you can trace the cause of bugs and stop them happening again. No software will ever be a replacment for good managment.

Improve this answer
9
  • The tracking software also helps keep track of bugs to fix. A sticky note can fall off, and if four people come up to you with bugs that you can work on right then you might fix three and forget the fourth. It's useful even if you pay no attention to the causes of the bugs.
    – David Thornley
    Nov 23, 2011 at 18:21
  • and to fix the problem with your team you could use gamification -> en.wikipedia.org/wiki/Gamification
    – marc.d
    Nov 23, 2011 at 18:23
  • 11
    @JoaoBosco: Hand-written tickets get lost, scribbled on, thrown out by accident... face-to-face conversations are great except when you're describing complex bugs to people that don't have photographic memory. People will forget things from conversations, not because they want to but because that's simply what happens.
    – FrustratedWithFormsDesigner
    Nov 23, 2011 at 18:33
  • 3
    @JoaoBosco: What about screenshots of GUI errors? Will you redraw them by hand? Samples of incorrect data output (if it's a database error, are you prepared to write n rows with m columns of incorrect data by hand)? Other forms of digital artifacts that are associated with the defect that just don't translate well to sticky notes? All of that stuff can easily be attached to a ticket in an issue tracking system. And if you're going to later convert your sticky note to text files, why not a database that lets you sort, order, categorize your tickets, then a little further to issue-tracking.
    – FrustratedWithFormsDesigner
    Nov 23, 2011 at 18:50
  • 10
    @user1062120: "If there is no place to keep bugs, people start correcting it more often" - or they start ignoring and forgetting bugs. It is not a "trick to motivate people" but an absurd attempt to relabel a weakness into a strength.
    – Michael Borgwardt
    Nov 23, 2011 at 20:11
12

IMO your starting point is biased. If the developers fail to fix the bugs, the project is doomed to fail, whether they track bugs using a proper bug tracking tool, post-its, stone carvings, or not at all. It's not the tool's fault if it is not used or misused. (That said, there are of course bad bug/issue trackers out there... I worked on a project using a totally inadequate tool for this job, so I think I know how bad it can be. But there are good ones too, which require minimal ceremony and overhead, allowing you to focus on the relevant information.)

If, however, the developers do care, and the project is larger than trivial in size, and there is more than a single developer on it, and there is some sort of management involved (all of which are pretty common in real-world projects), soon there will arise questions like:

  1. Which of the open bugs should be fixed first? (note: in a sane project, this should be decided by the product owner and/or management, NOT by a developer - for which they must be aware of all open bugs first of all!)
  2. How many open bugs we have, and of what severity?
  3. Which of these must be fixed before we are ready to release?
  4. How much time to plan for these fixes - often leading to: how much time it takes to fix a bug on average?
  5. how many bugs have been reported by clients in the last release?
  6. who did fix this-and-this bug, when, and what (code / configuration / data) changes did the fix involve?
  7. what bug fixes are included in the release we are just about to publish?
  8. ...

Can you answer such questions [update] repeatably, reliably and efficiently [/update] based on your post-it notes?

Yes, entering bug data into an issue tracker entails some overhead. However, it is more than compensated by the time and effort saved in looking up, and creating reports like the above, from the stored bug data.

Improve this answer
4
  • Post-its won't answer everything. It is just a tool. You can still prioritize them, make statistics about open bugs, fixed ones and etc. All I am saying is that I think that issue tracking systems can be more counter-productive than help you fix the management problems you have.
    – user1062120
    Nov 23, 2011 at 19:01
  • 7
    @user1062120: And all everyone else is saying is that you are very, very wrong. Post-its are an issue tracking system, just a very poor one that lacks a lot of essential features.
    – Michael Borgwardt
    Nov 23, 2011 at 20:09
  • @user1062120, of course in theory all of these could be answered using sticky notes - if you add unique IDs to each, keep adding detailed history comments on them (so you start to need rather big sticky notes after a while :-), and spend an awful amount of time sorting, re-sorting and rearranging them according to the current question (for which you might need to hire a new guy in a bigger project ;-).
    – Péter Török
    Nov 24, 2011 at 7:57
  • @user1062120, e.g. planning yields Question 1 above - let's rearrange sticky notes according to priority. Soon PM asks Q2: oops, rearrange by severity. But Q1 is still open, so now let's sort them all again by priority. Oops, 3 post-its were left out 'cause they were on Joe's desk - start all over again! Then Q6 - let's dig out the boxes storing historical post-its, browse through all of them by hand to find the proper one, then try to read the scribble on its back, meant to describe the changes... oops, someone opened a window nearby, rush to save your post-its from escaping by wind... etc.
    – Péter Török
    Nov 24, 2011 at 8:20
9

Your methodology may work for very small projects with a limited number of programmers. Once a project gets bigger, having a issue tracking system becomes much more important for coordination between different teams, particularly if fixes will be going out in different code releases. Complex projects will have many moving parts/components, and ensuring that problems are scheduled and fixed is a big part of a good issue tracking implementation

Some articles/studies that might interest you include this article discussing Zend's use of Jira and this French study discussing the use of bug tracking systems.

Improve this answer
2
  • 1
    Thank you very much for the references. I'll take a look at them. And yes, it is working within 3 small teams here.
    – user1062120
    Nov 23, 2011 at 18:36
  • 2
    +1 for the references, which were explicity asked for in the question.
    – mattnz
    Nov 23, 2011 at 21:09
4

There may be studies, but even better are the hard earned experiences of people in the field. Most issue tracking systems suffer from the processes that drive their design. Issue trackers often need to support 2 distinct classes of users:

  1. The development team
  2. The users of the system

Cal Henderson (formerly of Flickr) has a great post on the design of many issue trackers and why he prefers the GitHub issue tracker (as do I). Also, Garrett Dimon covered the design of Sifter and illustrated a way to simplify the process for more effective issue tracking. I've adopted some of the ideas from both os these posts to help simplify my team's issue tracking workflow.

All that said, it still comes down to people over process and tools. My general thinking is that issue trackers tend to create this backlog that you have to manage. During triage, people are more likely to rationalize what is or is not a bug. In our process, we make decisions almost as soon as the bug is filed about whether or not it is an issue. Once that decision is made, the bug goes into Pivotal Tracker. The difference here is that we use Tracker for prioritization, not as a holding pen for things we don't want to do. In fact when the Icebox starts getting too big I actively delete items, including bugs. If an issue is big enough that it needs to be handled, it will come up again.

We rarely need bug history. Occasionally, someone may mention a symptom of a bug and we may do a search to see if it is related to some issue we already handled. But, that is rare.

TL;DR Focus on your process, pick simple tools and address issues as they come up.

Improve this answer
1
  • That is exactly what I meant. We also prioritize items as soon as they appear and we also delete not important items. The important stuff will come back in time. I found that the overhead to keep track of everything is not worthy. The idea of having a small post-it white board is that you physically cannot register everything, just the important stuff. So this trick forces you to handle it as soon as possible. But that is my case, so I am not sure if it would work everywhere.
    – user1062120
    Nov 23, 2011 at 19:14
2

killing important bugs as soon as they appear

It sounds like you're breaking into the open door here. Important bugs get "killed" as soon as possible no matter if you use issue tracker or not.

  • Oh and part "as they appear" is quite slippery BTW. In one project we had an important bug that threatened to throw the whole product out of business (what could be more important?). It was very complicated (architecture error) and we knew it will take long to fix it. Customers kindly agreed to give us a year to fix (before dropping our product) and we did it in about a year.

As for issue trackers, I've been using these for almost ten years and as a rule, all programmers around me spent quite little time with tracker (note I am talking about programmers; managers are different story). I have seen cases (rarely) when it was not so - in all these cases something was severely broken.

Regarding studies on face-to-face conversations vs issue tracking, again it feels like you're breaking into the open door here. Issue tracking is a typical written communication; there are plenty research showing that to discuss things, face2face communication is much more efficient than over the phone which is in turn much more efficient than written.

  • Actually given that you ask about f2f it feels like you're (mis)using tracker to discuss things - this is not its purpose. To figure its intended use, just spell its name slowly and clearly: issue tracking system.

the bug lists gets so long

In my experience, above is an advantage not a problem.

With long bug list developers can set up a queue and plan fixes far ahead. This is as productive as it gets; to me this is basically a nirvana when I have such a queue to work with. First bug - fix - done, second bug - fix - done, next bug - fix - done etc etc. No stupid interruptions, no painful distractions with oh-so-efficient f2f conversations, pure flow.

  • I recall only one case when long bug lists have been a problem. It happened when some idiot at higher management decided on a policy that forced developers to pick next bug from a pile of 50-100 almost daily. What a waste. It took us a few months of pain until we figured how to escalate this over his head and get it fixed.
    Some time after we managed to establish convenient work flow we discovered that our "endless backlog" magically got empty.
Improve this answer
2
  • 2
    I recent spent 2.5 days wading through over 300 open bugs (mostly UI) accrued in over a year, all assigned either to freelancers/interns long gone, or to the project manager who didn't have tiime to deal with them. I found that I could close about half of them as already fixed or not anymore relevant. The rest are getting fixed at a decent rate after I assigned them to the right people. The bug tracking system was used poorly, but without it, all those bugs (no show-stoppers, but some quite ugly) would surely have been forgotten.
    – Michael Borgwardt
    Nov 24, 2011 at 9:10
  • 1
    @MichaelBorgwardt yeah lists so long that nobody can deal with it in my experience always turned out manageable as long as one doesn't get frozen by scary-looking numbers like 200, 400, 1000. I just did a quick check out of curiousity - for last year I fixed 300+ issues - I alone (!). Out of curiousity I also checked other guys in team thinking maybe I am unique - no, 200-400 fixes/year appear just an average rate. 500 bugs however scary these look, may be just half-year of work for 4-5 developers, piece of cake :)
    – gnat
    Nov 24, 2011 at 9:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.