Technical Debt: No Penalty for Early Payment

by

We are a debtor society. We go into debt for our cars, our homes, heck, thanks to credit cards we even go into debt for groceries and gasoline.

In software development, much like in life, a little debt can actually be a good thing to get other more critical things moving. Although in previous blogs we have defined technical debt as “the cost to fix structural quality problems in an application that, if left unfixed, could put the business at risk,” engaging in a small, manageable amount of technical debt can actually make a project move faster and facilitate reaching the objective of executable application software. This was the thought of Ward Cunningham, the originator of the technical debt concept.

But as Derek Huether points out in his technology consulting blog for Dumas Lab regarding technical debt, “Just like regular debt, you’re going to have to pay it back sooner or later. “

Huether also notes that much like the debt in our personal lives, if not paid back somehow:

…it will come back to haunt you.  If your kludge of a solution doesn’t come back to bite the development team, it will probably haunt the help desk, support team, or someone else downstream.

He then adds:

Just like regular debt, you’re going to have to pay it back sooner or later…, I’ve seen (and see) what technical debt can do to the velocity of a team.  It robs them of precious time, after the fact. The development team buys into the idea that doing things the wrong way, to save some time in the interim, is worth the risks and the overall cost.  This is a really short-sided [sic] thought process.  Technical debt is like getting a loan from loan shark who roles dice to decide what your interest rate is.  So, if you don’t need to take the risk, don’t do it.

But is technical debt really and “all or nothing” proposition?

How Much is Enough?

When it comes to Technical Debt, a company needs to determine how much, if anything it should put into remediating it.  The best way to do this is by monetizing technical debt to put a financial figure on application structural quality. This allows for comparisons between IT costs and potential losses due to failure that were previously not possible.

The goal of monetizing technical debt is to keep the number of structural quality violations – or more importantly, the cost to fix them – well below the cost the company would incur if application software were to be deployed and a failure ensued.

A Technical Debt Action Plan

In order to determine the tipping point of structural quality issues and the cost to fix them, a company should utilize a platform of automated analysis and measurement to evaluate the structural quality of their five most mission-critical applications. As each of these applications is built, its structural quality should be measured at every major release and once they are in operation, the structural quality of the application should be measured every quarter.

The key is to keep a watchful eye on the violation count; monitor the changes in the violation count and calculate the Technical Debt of the application after each quality assessment. When a dollar figure for technical debt has been ascertained, it can be compared to the business value to determine how much Technical Debt is too much and how much is acceptable based on the marginal return on business value. For a framework for calculating the loss of business value due to structural quality violations, we recommend, “The Business Value of Application Internal Quality” by Dr. Bill Curtis.

Once that tipping point is determined, a company can decide where and when it needs to address the issues of structural quality that created the technical debt.

The nice part about unloading technical debt is that like personal debt, it saves a ton on interest payments, yet there’s no penalty for paying it off early…in fact, it yields a significant reward of higher quality software.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Jonathan Bloom Writer, Blogger & PR Consultant
Jonathan is an experienced writer with over 20 years writing about the Technology industry. Jon has written more than 750 journal and magazine articles, blogs and other materials that have been published throughout the U.S. and Canada. He has expertise in a wide range of subjects within the IT industry including software development, enterprise software, mobile, database, security, BI, SaaS/Cloud, Health Care IT and Sustainable Technology. In his free time, Jon enjoys attending sporting events, cooking, studying American history and listening to Bruce Springsteen music.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|