calculate the cost to fix a defect.
| Date |
Size in LOC |
FFR (this week only) |
Average cost to fix a defect, pre-release |
|
1/1 |
425,000 |
14% |
1 person-days |
|
4/1 |
800,000 |
16% |
3 person-days |
|
7/1 |
1,500,000 |
12% |
2 person-days |
|
10/1 |
2,000,000 |
18% |
3 person-days |
It's always tempting to jump to conclusions from looking at the data. Don't. Probe and ask questions to make sure you know what the data really means. For example, the code size increased almost 50 percent each quarter. Do I think the developers are capable of writing that much high-quality code? What did the developers do, to generate that amount of code? Did they leave experiments (rejected designs) in the code? Did they hire more people? Did they use a code generator? If you'd like more guidance on what you should expect for increases in code size, see Capers Jones' book, Software Assessments, Benchmarks, and Best Practices .
In this case, it turns out that instead of re-architecting the code to account for new knowledge and changes in requirements, the developers were cutting and pasting code all over the system. The system was bloated, and every time the developers had to make a fix in one place, they had to remember the forty-seven other places to fix.
Then I look at the FFR. Does it make sense? What makes the FFR go up or down? In this case, the FFR started high, and aside from the third quarter, continued to go up. What happened in the third quarter to make the FFR go down? In the third quarter, one development team re-architected one small module that was originally a huge source of defects. With the new version, the total number of bad defects went down and the cost to fix a defect went down. They had paid off some of the "debt," so now they were paying less "interest" on the debt. You may also want to look at FFR by subsystem or module, to see if one subsystem or module is causing much of the defect-fixing pain.
The cost to fix a defect for this organization is extremely high. If the developers and testers find twenty defects a day, then they generate about sixty days' worth of work for every day of testing.
Let me know your thoughts on technical debt. My next column will provide pointers for diagnosing and decreasing the debt.
Acknowledgements
I thank Esther Derby, Dale Emery, Dave Smith, and Jerry Weinberg for their review on this column.
Pages
About the author
Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:
- Manage Your Job Search
- Hiring Geeks That Fit
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.
