I once worked alongside a chap who was a project leader in a large organisation. His team produced a new release of their system every 4-6 months, and so over a few years he ran quite a sequence of projects, all on the same codebase and all with the same team. He’s a bright guy, good at his job, one of the nicest people I ever worked with, and his story is quite typical. I’m sure you’ve seen something similar to what I’m about to describe.
During the second and third of these projects he diligently noticed that his programmers were spending a portion of their time fixing defects in previous releases. He diligently measured the time thus spent – at 10% of the project’s staff-time. And this was his perfectly rational reason for missing his deadline and dropping a couple of features into the bargain. During ‘planning week’ for the next round of projects he therefore proposed to set aside 10% of his staff’s time for fixing defects. He had the figures to prove that this was sensible, and the programme managers supported his plan. (In fact, they encouraged all of his peers to do the same.)
So for the next release his team spent 10% less time adding new features to the system. A thinking person might then have expected that the following project’s time budget would thus need to be shortened by only 9% – because surely 10% less product will have 10% fewer bugs, right? Wrong. The 10% figure never tailed off, and no-one ever noticed.
So either the bug-fixing time was being used to mop up other problems in the estimates, or the bugfixes contained as many bugs as the original code. At one point I suggested he spend the 10% of all future projects in implementing defect-prevention measures, but he didn’t have the time…