Will software publishers ever shake off their 'technical debt'?

How costly is 'technical debt' -- the amount of work that still has to go into software after it has been released? For too many companies, this is unfortunately too common a way of doing business. 

The challenge for many developers is their organizations put tremendous pressure on them to get things out the door as fast as possible -- to deliver releases quickly, allowing precious little time for bug reporting and fixing. In many cases, upper management seems to be more willing to assume long-term technical debt than pay a little more up-front to get things right, with better testing and quality measures.  

Ward Cunningham and Capers Jones, the two most respected leading voices on software quality, recently renewed their calls for better management of technical debt in a recent Q&A, hosted by Carolyn Seaman and reported by Alexandra Szynkarski at OnTechnicalDebt.com

As Jones put it: "If you skimp on quality before you deliver software, you end up paying heavy interest downstream after the software is released for things you could have gotten rid of earlier, had you been more careful." Cunningham adds that applications themselves have a way of taking on a life of their own -- turning into "its own little bureaucracy where you can’t actually on a daily basis create value." The result is technical debt that "has piled up and you’re paying that interest."

As Jones describes it, most companies still carry high levels of technical debt, but there are some shining examples of "debt-free" companies as well:

"Most companies don’t have a clue on how to get rid of bugs before release. So they’re not making conscious choices; they’re acting out of ignorance because they don’t know what they’re doing. If you look at the companies that do know what they’re doing, they don’t have much technical debt and they don’t have to pay very much up front either because they’re using a synergistic combination of defect-prevention, pretest removal, static analysis and inspections, and really good testing. So they have minimum upfront cost and they have minimum technical debt because they know what they’re doing."

Jones puts the average cost of technical debt -- resulting from botched projects -- at $1,200 per function point in the development stage, $600 per function point for fixing bugs, and $300 per function point after release fixing bugs. This costs escalates after five years as well -- to about $350.

By contrast, a well-executed development process can deliver software at about $1,000 a function point for development, $500 for fixing bugs, and $200 for post-release bug fixes. In a well-managed quality organization, the cost should drop to $50 a function point after five years, he states.

For measuring technical debt, Jones points to a tried-and-true metric called “defect removal efficiency,” which encompasses keeping track of the bugs found during development, and keeping track of customer reports up to 90 days after release. The number of customer reports is calculated against the number of internal bug findings. "For example, if you found 90 bugs inside and the customers reported 10 bugs, you were 90% efficient in removing defects," he illustrates.

Companies with notable software quality efforts "achieve something like 99% defect removal efficiency, so only 1% of the bugs get released into the field." The U.S. average is only 85% defect removal efficiency, he adds. "For a software organization to release 15% of all defects to an excited public, to my mind, is hovering near malpractice." In other words, don't rely on end-users to serve as beta sites, he says.

(Thumbnail photo: James Martin, CNET.)