In ancient neolithic farming communities, the size of the average tribe or village was about 150 people. That’s also about the size of most military units dating back to Roman antiquity and earlier, and it’s a number that features frequently in a variety of social antropological examples. It turns out, as Robin Dunbar popularised with his research from the early nineties, that 150 is about the number of individuals a single person can maintain a stable social relationship – that is, where you know who each of the people are, and how they relate to all the other people in the ‘network’. Malcom Gladwell talks about this extensively in his book Tipping Point.
The same is true, I think, for bugs in a software system. We have the ability to understand, process and relate to a relatively small and definitely finite backlist of bugs. I don’t know if 150 is exactly the number – and it would probably depend on the product and the type of bugs – but I think it’s close enough.
Many software projects have the tendency to track hundreds or even thousands of defects in long, long lists, maintained and even driven by complicated tools. Having so many bugs open makes it very difficult to see what’s truly important. With 800 bugs in the system, answering the question “what’s important today?” is hard.
You also need to deal with the fact that a large portion of these bugs won’t ever get fixed. They just won’t. Not because we don’t want to – at least not exclusively – but because a team can only fix so many bugs at a time. With such a large bug backlog the world around you changes quicker than you can fix all the defects, so many of them will end up being invalid or no longer relevant long before they could have been actually fixed. So was it worth tracking them in the first place?
Software development blogger Gojko Adzic thinks we should do away with bug tracking completely. I don’t think I would go so far: I think recording bugs in some kind of tool is necessary to see the major open problems with the software, allow scheduling of fixes and provides an important communication channel especially with offsite or offshore teams. I don’t think, however, that it is valuable or efficient to record every one of 1001 defects that were ever discovered.
Just like the stone-age farming villages, I think a team has the ability to deal with about 150 open defects at a time. Any more is just noise, and is probably going to cost (read: waste) you a lot of time in adminstration and error management that you won’t get a meaningful return on. What if you kept a record of the top 150 defects, and just dropped the rest? Just don’t record them?
The natural question to ask at this point is rightly “what are the top defects?”. The word ‘top’ is all about priority, and priority is a very context sensitive thing. Priority is relative to the vision of the product, the maturity of the software, the type of users and other product related factors; but priority is also relative to the priority of the other defects in the system. If your payment system is dropping payments or sending cash to the wrong accounts, then that layout issue on the invoice page is not going to be so important. But if the payments are processed perfectly and the layout problem is the only blemish, then it’s ‘top’ priority, relative to the other open issues.
Here’s a proposal: Define a minimum bar for defects; one that keeps your bug count at about 150. As the highest priority items are cleared up, then the priority of the next ones increases relatively – so you raise the bar in terms of which defects can be added. If your bug list grows over 150 (hopefully it doesn’t!) then drop the bar to stop recording stuff that you don’t have time or headspace to care about.
If you don’t care about it, then just drop it. If part of you cares but you have a hundred other more important things, then drop it too. Spending effort and time recording stuff that you’re team is not able to deal with just creates noise, consumes effort and makes it hard to see what’s important.