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

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

Summary: For software and anything else, it's far cheaper to do things right the first time, say software quality proponents Capers Jones and Ward Cunningham.


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.)


Topics: Software Development, Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It's impossible to avoid.

    "How costly is 'technical debt' -- the amount of work that still has to go into software after it has been released?"

    It's impossible to avoid. Even when you wrap up every bug report before release, even if you do your darnedest to test for and find all bugs before release - you're gonna make a long list after release and will keep adding to it throughout the life cycle of the product.

    That's not to say they're completely wrong - if you *do* make sure the quality is high before release, your so-called "technical debt" (who came up with that name?) will be pretty manageable after release. But it will never rid yourself of it completely.

    BTW - assigning dollar values to "function points"? Completely bogus. There's no way to assign a dollar value to them. They have no relation to money.

    There is also no "tried-and-true metric" to bug removal efficiency, contrary to your claim. And if you're only counting your bugs after 90 days, you're doing your customers a horrific disservice. Software should be maintained years after release, not months. I'm gonna say upfront that that methodology sounds completely bogus.
    • Well said, CobraA1

      And the fun part is, some managers read the stuff put out by consortium groups that say these same things you're responding to and believe it carte blanche.

      They're the same ones who ditch quality antivirus software just because they're paying for an umbrella Enterprise licensing scheme, not realizing that what's slopped into the license is nowhere near as good as the paid competition that actually does the job and prevents malware from taking down entire LANs.

      Today's managers are myopic and parochial, putting $ above common sense and other sorely missing facts. But they're just looking after their own job.

      Just wait until the cloudy server goes down, or if data is stolen from there. The manager won't feel too warm and cozy then...
    • RE: It's impossible to avoid.

      Not so. Here's a link to OpenBSD errata:


      Note the drop in the number of errata for each release after 4.8, including 4.9, 5.0, 5.1 and 5.2. Quite amazing, actually.

      Of course, when a user installs a desktop environment, web browser, email client, etc. or a web server, database server, etc., there will be errata at varying frequency for each. Then again, the developers at the organizations responsible for applications (all open-source, btw) aren't as committed to software quality as is the OpenBSD project.

      More here on OpenBSD's secure auditing process:

      "We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better.
      Rabid Howler Monkey
    • Interesting report and responses

      It all depends on the management. If the managers have graduated from the field of Software development and understand what it takes to right a fit for release software, they would also plan better and introduce to their system what we may term as management by expectation, which simply implies all the contingencies plans for the release of product would be there.

      They will take into account development time, proper QA time and then start feeding the dogs - UAT. Once they are happy with the result and know they can manage the post release issues of the application, would they only release.

      However, in the real world, we do have managers, who have little or no experience in software development. These breed of managers are the champions of buggy software releases! And this introduces an interesting and sometimes hair-raising challenges to the developers, where they have to engage in fire fights and the art of management by crisis becomes part of their daily work - more sweat for each bug fix. Even sometimes eBay it is called a bug could be simply a design flaws that muted into bugs.

      One thing though: softer releases should not be mean there is no maintenance after it has been released. But the maintained should be mean improving the software, while also fixing bugs.
  • Proprietary Software Or Free Software?

    It's harder to get away with crap in the Free Software world, if your software is any use at all. Somebody will get sufficiently annoyed to work up a patch, and if you act all precious and refuse to accept reasonable patches, you are liable to see your project forked right out from under you.
  • Not really true

    If a company releases a new sw (product) just 1 or 2 months earlier it enjoys the benefit of earning millions of $ which can easily make up for the later loss in bug fixing.
    Take a 3% interest rate on $ 3 mio earnings and you can fix a lot of bugs later.

    Most customers don't care that much if a software is pretty buggy. As longs as it is not too bad.

    That said : Economically, it makes sense to release beta sw and fix it later.
    • RE: Economically, it makes sense to release beta sw and fix it later.

      I agree with this as long as the beta release is well-publicized as a beta release, is "free" as in "free beer" if it is proprietary software, is of limited duration and the bugs are fixed prior to a stable release.
      Rabid Howler Monkey
  • Fix the system. Stop blaming symptoms as being the root causes.

    Everything is moving too fast for its own good.

    Some claim that it's economically sound to shove broken garbage out to users and to (hopefully) fix it later. All that's gotten anyone is broken software they loathe, hate, and scream out lout over and I've not mentioned what support technicians have to endure yet.

    Some put out flawed gear, despite engineers saying it was flawed. Then those CEOs try to blame the customers, like saying "you're holding it wrong". Any SMB trying to act so devolved wouldn't last. Let the larger companies do last, and it's not due to having a better product - not when so many complain about so many bugs, which seems to be a far worsening problem... so, no, it is anything BUT "economically sound".
  • Faulty Analysis

    For one thing, marketing has dominated computer and software design for decades now. I still remember when Oracle's first DB effort was a laughably dysfunctional piece of alpha-level crap, but the money they got from early adopters was enough to fuel their R&D to get things eventually fixed. By the time Microsoft releases a new OS to market, they've already been hard at work on not just the next OS release, but have likely even started work on the one after that. Those annoying bugs in Windows 7, especially in regards to networking, will likely never be fixed now that Win8 is out. And being able to outsource lower level coding tasks and software development to India and such on the cheap cuts costs enough by itself to justify not bothering with tying up your top-tier coders to work out remaining bugs or finish QA, even if the final result is a buggy, insecure product (looking at you especially, Adobe.)

    People who are technically aware enough to recognize shoddy design and execution are in the tiny majority of users, and a whole generation of computer users have become accustomed to software, computers, and and network/Internet access being temperamental, quirky and insecure to some degree, so there is an acceptance of that being it is what it is.