Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Next, one finds that debugging has a linear convergence, or
worse, where one somehow expects a quadratic sort of approach
to the end. So testing drags on and on, the last difficult bugs taking
more time to find than the first.
From “The Mythical Man-Month, Chapter 1 The Tar Pit”.
What’s the meaning of linear convergence here , could you give me a popular example or a graphics?
What Fred Brooks means is that management expectations of the rate at which finding, fixing, testing and closing off bugs will somehow increase at a quadratic rate is unrealistic. Brooks asserts that the rate of closing off bugs is at best time linear, and may in fact be will be worse than that.
In a picture, and assuming a utopian target of exactly ZERO bugs and defects, here’s “Quadratic Closure” (green), Linear Closure (orange) and a worse-case decaying exponential (Red).
I agree with Brooks – Management’s expectation is based on the assumption that as developers complete coding, that more and more of the development team will be allocated to debugging, which should increase the rate of bug fixing.
However, in reality, the easy bugs get found and fixed quickly, but more insidious defects are much more difficult to find, hence the long tail often experienced on project bug closure.
There’s another reason why bug counts don’t burn down at linear rates or better – even in most modern, professional software development houses, more testing resources are allocated to the project later on in the development cycle than in the early stages, and of course, as more code gets developed, the more bugs are introduced, and with more testers, more bugs are found. This means that the initial bug count is hopelessly under-reported, and the total bug count will actually increase for long periods of the project.
A more useful metric is the nett rate of defect closure. Here, teams generally look for the point at which the rate of closure crosses the rate of new defects being reported – this is taken as a good sign indicative that the end of the tunnel may be in sight.