Treating Bug Management Like a Flow Problem

At the moment I am managing the bugs for a project. I am responsible for triaging the bugs, allocating them to the right resource and generally making sure they get attended to.

One interesting aspect of this process is trying to predict when the bugs will be completed. The issue reminds me of the flow problems I used to work on in my physics days.

A Simple Bug Model

In this project, all bugs are in one of three states:

• Active: The bug is not fixed
• Resolved: The bug has been fixed and is ready for testing
• Closed: The bug has been tested and found to be fixed

The client creates active bugs, the consultant resolves bugs and the client closes bugs.

The Physics of Bugs

The problem reminds me of a flow problem with sinks and sources. In this case our source is the inflow of new bugs and our sink is the bucket of closed bugs. The resolved state is like a leaky bucket with bugs flowing in from the active state and flowing out through a hole to the closed state.

The Maths of Flow Systems

Flow systems have rules of conservation. For us the rules are:

• New bugs can only enter into the Active bucket
• Bugs cannot be destroyed
• All bugs eventually end up in the Closed bucket

Source and Sink Rates

Here are some mocked up data to see how we can apply our model to the bugs.

Date	Active	Resolved	Closed	Total
2014/03/17	25	11	6	42
2014/03/18	23	15	7	45
2014/03/20	21	18	7	46
2014/04/02	24	20	14	58
2014/04/04	22	25	16	63
2014/04/07	20	27	16	63
2014/04/09	11	34	20	65
2014/04/10	10	38	21	69

The data, in itself, is hard to gain insight from but the rates are a little more telling.

For us, we will look at the average flows over time. Firstly, the source and the sink rates.

• Average Bug Creation Rate = (69-42)/24 = 1.125 bugs/day (source rate)
• Average Close Rate = (21-6)/24 = 0.625 bugs/day (sink rate)

Here I have taken the difference in days, but you can also use ‘working days’ if this suits better.

This immediately tells us that bugs are being created faster than they are being closed. Therefore, if things remain the same, the bugs will never be finished. Let us revisit this a bit later.

Resolution Rate

All Active bugs must go to either Resolved or Closed so, with this information we can calculate the rate at which bugs are leaving the Active bucket i.e. the rate of Resolution

Rate of Leaving the Active Bucket = (59-17)/24 = 1.75 bugs/day

So we now have the

• Rate of Bug Creation (1.125 bugs/day)
• Rate of Resolution (1.75 bugs/day)
• Rate of Closure (0.625 bugs/day)

What the Rates Tell Us

In the bug-fixing stage of a project, there is always pressure to get bugs closed. Often project payments are contingent on critical bugs being closed. Go-live dates put pressure on client and consultant alike to get the bug-fixing job finished.

Firstly, as we noted before, the Rate of Bug Creation is greater than the Rate of Closure. Bugs are flowing into the system faster than they are ending up in the Closed bucket. This means, if things continue as they are, there will always be Active and Resolved bugs in the system and they will continue to grow.

However, the Rate of Resolution is larger than the Rate of Bug Creation so the consultants are actioning the Active bugs but they are staying in the Resolved bucket with only a trickle into the Closed bucket. The consultants are doing what they can but the client is dragging the chain on closure. This is excellent information for a project manager to know, who may be negotiating the situation with the client or having to report to their bosses on why the project is getting delayed.

Conclusions

The model employed here is quite a simple one. For example, if the client does not accept a Resolution, the bug will return to Active, but it provides a foundation for analysing bugs through rates of change and gaining insights which otherwise may not be apparent. Other extensions of this model may be rates of change of the flow. For example, it is reasonable to expect the rate of bug creation to taper to zero as testers run out of things to test, that is, the rate of bug creation will decelerate over time. This can be calculated and fed into the model for greater accuracy.

See how you go and, if like above, you find out that there is more to the picture than too many bugs and not enough action, your team will thank you for it. Good luck.