There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

134

A team of one benefits from bug tracking software.
–
DominicMcDonnellFeb 28 '11 at 20:35

26 Answers
26

I think all the "yes" answers go a long way to endorsing the idea. But I'm going to throw out the idea that the decision is based on a few questions:

How do you want to communicate as a team? With 2 developers, you are now a team. How do you want to communicate? Plenty of agile teams live with in person discusions and white board sketches. But they may also go so far as to write things down, especially if it's a bug that won't be high on the priority list for a while.

How do you want to communicate with your customers? I don't know the answer to this, but if you have any reason to publish bugs (or fixed bugs in a version release document), then you're going to end up writing them down eventually. Might as well pick a low-stress bug management system and be done with it.

Is there value to preserving history? The answer may be "not right now" but if you think that in the future, you'd like to see the trend of bugs so you can see places that users are having the most problems, or places where you could spend some time checking and reviewing before a major release - then get a bug tracking system. The thing about history is that the day you want the record is not the day you should start keeping records.

IMO, the answers to these questions are more about where you see the product going and how you want to grow your team and less about whether "2 people = reason for bug tracking system". The bigger question is probably "is a bug tracking system worth the time to configure & manage and the cost of purchasing?"

1, but only if it's painless. GitHub for example has a very simple and usable issue tracker with more than enough features for a small team. Bugzilla, Trac or others are good, but they all require hardware, installation and configuration before use, and maintenance is definitely a non-zero expense.

Bugzilla can probably be installed in a virtual server for a pretty minimal cost.
–
Zachary KFeb 28 '11 at 15:21

2

Trac also doesn't take much for maintenance. I've had a Trac instance running about 2 years straight and have never had to maintain anything apart from adding new projects.
–
whatsisnameFeb 28 '11 at 16:40

2

I know both of them are easy to maintain, the point is rather that it's a "non-zero expense", i.e., not free. Maybe a few hours per year if you want to install security patches, or a few days if you need to migrate from an old version or your hardware dies.
–
l0b0Feb 28 '11 at 16:42

We had a very tiny team the first time I used bug tracking software and I was amazed at how much stuff we had been thinking we needed to fix that somehow never got fixed. It's totally worth it no matter how large your team is.

Good point. Psych research tells that people can keep ~7 items in their short term memory. If you have more than ~7 items on the todo list, bug tracking is a good idea. If you're writing them down anyway, you may well do it in a scalable and systematic way (it's not much more effort).
–
dbkkMar 1 '11 at 4:50

Don't even think of it in terms of bug tracking but as ticket tracking.

Being able to see all your tasks in tickets has a huge advantage. You can keep a history of a task in one place. You know who worked on it and when. You can be as detailed as saying what was completed on what day for a task.

For bug tracking, you can place all your bugs in one place and keep track of what ones have been completed and what ones are still in progress.

Face it, whether you buy a formal software solution or not you are going to have a bug/feature tracking system. It may be in notepad, it might be sticky notes, it might be in a block of comments at the top of your code. However, unless you are just randomly developing you will be jotting down your to-do lists somewhere. Why not use a more organized system that can grow with your team?

Also worth considering: Many of the bug-trackers are free for use by very small teams (1-2), so it isn't like you are incurring any major expense for the benefit.

Developer turnover - allows for knowledge transfer even if you get hit be the proverbial bus.

You will probably want to look at something that won't take much time for you to setup/manage. I would also suggest looking for something that includes that ability to integrate it with your source control.

If you have less then 3 you can probably get by with a google docs spreadsheet, maybe, I guess. But really the cost of installing bugzilla or the like somewhere is so trivial next to the cost of a programmer that you are better off just doing it. (Plus when you grow to 7 it will already be there)

Even a team of one can benefit from some sort of bug tracker, be it a text file of notes, or some full blown software. For 2 developers, I would recommend only investing time in setting up some bug tracking system, not money. Depending on the project, you can get by fine with writing bugs down on paper, maintaining a list through a shared online document, or using free bug tracking software such as Trac or Bugzilla. Fogbugz is also available as a free trial for 45 days.

Just start using one

If you just start using one you will begin to realize their convenience on practice, much like version control software, or for that matter, distributed version control.

Development maturity

It doesn't matter if you have a team of 100 or 1, I started using bug tracking and distributed version control (makes a lot of sense because of local commits) for myself and myself only and I already felt at another level, but not only that, I could manage my work at another level... to a level it could scale without me investing more effort.

By using a tracker you can anticipate problems and prioritize work, bug/issue trackers are not only for bugs/issues, they are more for project administration, and each and every project should have that.

For me it is not just about the software, but the process that goes around it. In my day to day job as a Test Manager I basically live in one and it provides the following benefits:

I find this works really well with 2+ testers and 3+ developers.

Management of developer bug fixing efforts

We actively manage a developers "bug queue" to control how much work they have assigned to them, and ensure that we have a level allocation of bug fixing work across the team.

Deciding what does and not get fixed

Triaging through new bugs on a daily process is a great way to help focus on what you do and don't fix, as well as when you fix it. Early on in a project, you want to fix everything. At the end you only want to fix show stoppers, and the bug tracking tool is great for that

When you need metrics

The big thing for me is Metrics, i.e. when you want to be able to view bug find and fix trends, where the buggy areas of code are, or how quickly testers are finding and re-testing bugs. It's time for a bug tracking system.

I agree with the common opinion that one team member is enough to start to need a bug tracker. I'd characterize it as mandatory after you have one or two real users, but important well before your first release.

Personally, I like fossil for both source control and bug tracking. It is a complete low ceremony distributed SCM that is well integrated to a bug tracker and a wiki. And it is a single-executable install, broadly portable, and uses an internal web application as its GUI. Its home page is actually served almost entirely by a copy of fossil.

With the tracker tightly integrated with revision control, you can easily link changes to tickets, and see ticket updates in the same time line view as revisions (and wiki page edits).

I've used bugs everywhere when working just by myself. It works with your DVCS by keeping bug info together with your source. Very low overhead as it requires no central server. The downside is you have to be careful which branches you enter new bugs into to make sure they propagate in a timely manner, although it may not matter much if you mostly want to track your own bugs and what was fixed in your latest pull, rather than track a team's status as a whole.

Yes, yes, yes, yes! Being able to track, prioritize, and manage your issues is key to successful software development. With one person, you can (almost) get away with a spreadsheet and zipping up old source trees. Adding even one developer to a project changes things dramatically -- suddenly, issue tracking and source code control is necessary, or you're going to be dropping issues, overwriting functionality, and generally having a miserable time of it.

I'm surprised that no one's mentioned StackExchange's parent company, FogCreek, yet -- their FogBugz software is the best issue tracking app I've ever used. High speed, low drag, and affordable, especially if you use their hosted solution. They used to have a free hosted trial that had, I believe, two user licenses free -- that may not be the case anymore, but I'd recommend checking it out.

If you have a minimalistic bug tracker, I'd say it's useful even for a team of one. Over at one of my friend's project sites QuokForge, they provide basically a Red Mine instance for each project. Red Mine, in my opinion has a good bug tracker(even if a bit strange at times). Namely because you can file a bug by only entering text in ONE field. I've also used FogBugz before. It's free for 2 or less people. And it allows the same simplicity, filing a bug by filling out only one text field. (It also provides graphs and other things that are insanely useful)

Basically, don't make bug filing a strict and formal process requiring you to set aside 30 minutes to fill out a bug report(BugZilla, I'm looking at you). This just means that people won't use it.

Finally, having a bug list(even if all each bug contains is about 50 characters of text) is extremely valuable. "Hmm, bout to release 1.0. I THINK I fixed the last of the bugs." And it's also great for managers to see you're actually doing something :). In a team, it's more valuable because you're not both trying to keep a different set of mental to-do lists in your head. And it fixes the "Did you fix that [really bad security bug]? Um, yea I THINK so. Ok let's release 1.0 then."

I also love keeping track of features as well. This is a bit more optional but I still find benefit from being able to offload the mental task of keeping a todo list in my head.

You have just reached that number... 2! While I can see the benefits of using bug tracking software even if you are the only developer... you can just get by without it when the total number of developers is 1.

However, as soon as you have two or more developers, there is not a single reason not to have bug tracking software, not one.

I assume by investing you mean time. There are plenty of free bug tracking systems out there, that should be fine for a two person team. I wouldn't look into commercial offerings until I had a bigger team.

Issues have short life-span. In this case it might be enough with a simple task board (since it's smart to visualize the workflow for a lot of other reasons). However, if you can't resolve issues quickly, f.ex. fixing bugs quickly, you will find it useful to track the issue.

Code changes are documented with automated tests as living documentation. I.e., bugs and fixes are documented with failing tests when they appear, with passing tests becoming regression tests after the fix. - And functionality changes are documented with automated acceptance tests (f.ex. using some BDD tool like FitNesse or Cucumber). Such documentation should be easily available from a CI server like Jenkins.

How do you remember the bug is fixed? How do you remember you didn't miss a bug before making a release?
–
EarlzMar 1 '11 at 3:49

2

Sorry man, looks like you are trying to make a point, but it is moot.
–
dukeofgamingMar 1 '11 at 3:56

2

@Steven: Ever had a product with a 7-digit number of installations? No amount of TDD will prevent several thousand users filing bugs, let alone several million. They might not even be real bugs to be fixed on your end, but you will still have to look at them, close duplicates, pointing customers to the solutions to the original ones etc. If you are a one-man company, you will either have to resort to pen/paper, Excel, your own DB - or you just use some software made for this.
–
sbiMar 1 '11 at 13:59