How big of a team do you need to benefit from bug tracking software? [closed]

Question

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?

Answer 1

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?"

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

The short answer is yes.

Some reasons why:

1. Ability to log bugs that have been found against specific versions.
2. Ability to know which (known) bugs haven't been fixed yet.
3. Track who fixed a bug that has since been found again.
4. 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.

Answer 8

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

Answer 9

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)

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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).

Answer 17

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.

Answer 18

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.

Answer 19

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

Answer 20

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.

Answer 21

Yes. And a recommendation is bitbucket http://www.bitbucket.org They provide free bug tracking as well as free Private repositories in mercurial.

Answer 22

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.

Answer 23

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?

Answer 24

It might not be worth it if the following two conditions are present:

1. 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.
2. 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.

Answer 25

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.