My development team just grew by 100% (from 1 developer to 2). My new cohort want to invest in bug tracking software. Is there benefits to such software for such a small team?
-
136A team of one benefits from bug tracking software. – Dominique McDonnell Feb 28 '11 at 20:35
-
5You might want to try the FogBugz Student and Startup Edition - very easy and convenient to set up and use (http://www.fogcreek.com/fogbugz/StudentAndStartup.html). – Maxim Zaslavsky Mar 01 '11 at 01:48
-
1@MaximZaslavsky: I did not know about that, I'm checking it out and It looks great, thanks! – Trufa Mar 01 '11 at 02:43
-
2even a team of < 1 person needs bug tracking sofware ... – vrdhn Mar 01 '11 at 04:29
-
Even Captain Spock benefits from bug generating software. – Mateen Ulhaq Mar 01 '11 at 06:19
-
5@Vardhan A team of less than one person? Like, a non-existent team? – Ikke Mar 01 '11 at 07:54
-
I like how the Kiwi bird, on Fog Creek's site, animates on mouse over :-) – invert Mar 01 '11 at 09:15
-
1Don't forget to invest in a good source control system too, if you haven't already. – invert Mar 01 '11 at 09:16
-
The Student and Startup Edition at Fog Creek includes [FogBugz](http://www.fogcreek.com/fogbugz/) AND [Kiln](http://www.fogcreek.com/kiln/) (source control). – Chase Florell Mar 01 '11 at 14:56
-
2@Ikke .. like one person working on multiple projects .. and keep forgetting what's to be done on multiple projects ... the managements call is 0.5 resource !! – vrdhn Mar 02 '11 at 05:51
25 Answers
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.

- 11,014
- 2
- 43
- 47
-
6Bugzilla can probably be installed in a virtual server for a pretty minimal cost. – Zachary K Feb 28 '11 at 15:21
-
2Trac 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. – whatsisname Feb 28 '11 at 16:40
-
2I 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. – l0b0 Feb 28 '11 at 16:42
-
Expense of installation is non-zero, but if well used will be far less than the gains of having it. – BillThor Feb 28 '11 at 17:26
-
Bugzilla and Trac are also available as hosted services (usually packaged with an SVN repository). Distributed VCS like Git have advantages, but SVN may be more straightforward for a small team. – dbkk Mar 01 '11 at 04:47
-
@dbkk: After having gone CVS -> SVN -> Git with more than a year on each, I can't recommend Git enough over the others. It is simply a delight, even compared to Subversion. – l0b0 Mar 01 '11 at 11:05
-
2
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?"

- 7,625
- 1
- 26
- 35
-
Very well put! Pick a tool that optimizes the way you want to work! Otherwise, use a corkboard! – Andres Jaan Tack Mar 01 '11 at 09:06
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.

- 28,709
- 4
- 67
- 116
-
I can **totally** relate to this. Just yesterday I lost my notebook where I wrote down some bugs that needed fixing. Now I'll have to waste another two hours going over the problem area. I'm going to download Bugzilla or something. – Feb 28 '11 at 15:34
-
3Good 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). – dbkk Mar 01 '11 at 04:50
Yes. A thousand times yes.
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.
It just helps you manage things so much better.

- 9,528
- 1
- 34
- 54
-
+1 for mentioning the 'ticket' tracking. It would be stupid to store only bugs in such a system, if you can use it also as personal todo list, future version planning, ... – stijn Feb 28 '11 at 16:10
-
Seriously you have to tie bug tracking to your revision control system. Then all changes have a reviewable reason. And you *have to have* a RCS of some kind. Not using both is like coming to work without pants. – Tim Williscroft Feb 28 '11 at 22:17
-
Yep don't call it "bug" tracking. We call it "task" tracking, since a bug is a task, but a task is not necessarily a bug. – Carson63000 Mar 01 '11 at 00:17
It is worth it with a team of one or more.
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.

- 19,052
- 8
- 65
- 112
You don't need any bug tracking software so long as every member of the team
- Has a perfect photographic memory, and
- Can synchronize their thoughts with every other member of the team.

- 4,810
- 2
- 16
- 23
The short answer is yes.
Some reasons why:
- Ability to log bugs that have been found against specific versions.
- Ability to know which (known) bugs haven't been fixed yet.
- Track who fixed a bug that has since been found again.
- 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.

- 755
- 6
- 10
This answer is to add weight to the YES side of the argument.
I am mostly a team of one. I extensively use issue tracking (redmine) together with SVN integration.
It is truly superb and I would go crazy without it; my quality would drop because I'd forget about things, and I'd loose track of what I've got to work on.
Productivity tools:
- Decent IDE
- Issue tracking
- Source Control
Issue tracking; don't leave home without it

- 283
- 1
- 3
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)

- 10,433
- 2
- 37
- 55
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.

- 916
- 6
- 10
Yes.
You need to track them some how!
The issue is how many bugs you have rather than how many developers. You can manage with an excel sheet when dealing with a few bugs, but even then its not the best.

- 14,674
- 4
- 37
- 73
There is definete benifet - I use bug tracking software even on personal projects. It's useful not only for tracking bugs, but also for tracking 'TODO's and feature requests.

- 1,328
- 9
- 15
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.

- 146,727
- 38
- 279
- 479
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.

- 13,943
- 6
- 50
- 77
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.

- 281
- 2
- 4
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).

- 291
- 1
- 5
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.
here is my 2 cents.
for bug tracking i just use a google-doc spreadsheet, i can invite anyone i want to to edit or view it. its free so not much of an investment. i keep track of all tasks on there to just bugs.
i also run SVN on my web-host which doesn't add any additional cost to web hosting.
some clients have required the use of unfuddle or other such project management / bug-tracking software but i would prefer the free solutions i mention above.
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.
Also, see what Joel had to say about it

- 22,658
- 7
- 46
- 60
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.
Yes. And a recommendation is bitbucket http://www.bitbucket.org They provide free bug tracking as well as free Private repositories in mercurial.

- 339
- 1
- 7
It might not be worth it if the following two conditions are present:
- 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.
If 1 or 2 isn't present, you will benefit from issue tracking.

- 151
- 1
- 3
One. In which case it's more like a To-Do list.
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.

- 2,141
- 2
- 16
- 15
I think your question has highlighted your misconception. For it is not the team that needs bug tracking, it's the product(s).
So, does bug tracking need to be done in software? Well, that would help, don't you think?

- 262
- 2
- 6
No
Don't track bugs, fix them.
It's not the size of the team that matters, it's how long you are willing to look at bugs on a list before fixing them.
If you're using Agile/TDD, your bug list will be short, and bugs will not linger on the list for long. Any tracking system will suffice in that case.

- 33,808
- 2
- 84
- 151
-
-
2How do you remember the bug is fixed? How do you remember you didn't miss a bug before making a release? – Earlz Mar 01 '11 at 03:49
-
2Sorry man, looks like you are trying to make a point, but it is moot. – dukeofgaming Mar 01 '11 at 03:56
-
@Earlz: I use TDD. Production bugs are rare. Each bug gets a unit/regression test. They don't come back. Everything is recorded in the developers' log for historical purposes. We used to have a bug list document, we don't need it any more. – Steven A. Lowe Mar 01 '11 at 04:20
-
@dukeofgaming: yeah i'm not making my point very well, but that's ok. We used to have a bug-tracking document but we don't need it any more. – Steven A. Lowe Mar 01 '11 at 04:21
-
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. – sbi Mar 01 '11 at 13:59
-
@sbi: yes, I have. We used custom bug-tracking software for it. But where in the OP's question or profile did you get the impression that he and his new partner are in that situation? My read on the question is that the bug-tracking software is for the purposes of communication _among the two team members_, which strikes me as going right off the rails. – Steven A. Lowe Mar 01 '11 at 20:12
-
2@Steven: My psychic abilities fail to see that far into Jim's unstated needs (and there's certainly nothing in the question indicating your interpretation). – sbi Mar 01 '11 at 20:44
-
@sbi: the question title implies that interpretation "how big of a team...". If your interpretation were warranted, the question would be "how many users..."! I agree with you though that the team size is not the critical factor. – Steven A. Lowe Mar 02 '11 at 02:03