Paying technical debt

The term Technical Debt was originally used in the early 1990s by Ward Cunningham as a metaphor describing software development practices. Over the last three decades, the term has taken on a broader meaner and can now refer to technology practices in architecture, coding, testing, operations, and even security. While the original metaphor doesn’t fully capture the use of the term today, the newer meaning describes a battle all companies are facing.

My definition of technical debt is the aggregate cost of replacing or updating technology that is unsupported, out-of-date, inefficient, or feature deficient. Examples of this include unsupported vendor software, software that no longer receives vendor patches, and custom software lacking customer-requested features because they were left-out to meet a deadline.

We’ve never worked in a time where the growth rate of technical debt has been greater than today. 

Bob Williams

Here’s why:

  • Cyber security and data breaches have elevated the importance of keeping the latest vulnerability patches applied to operating systems, software applications, and network devices. This puts a stake in the amount of time perpetual on-premise software installations can run without updates.
  • Modern software development practices promote speed and agility to deliver solutions on rapid release intervals. This is great for speed to market and releasing faster for the customer. However, it also increases pressure on programmers to take design shortcuts that later lead to larger code refactoring efforts.  
  • Compliance related controls for security and availability prescribe specific practices for keeping hardware and software secure and updated. 

Just like personal debt, technical debt left unchecked can lead to ruinous consequences including failed compliance checks, incompatible software integrations, and slow-performing software. Just like personal debt, the larger technical debt grows, the longer it will take to pay-off. Save us Dave Ramsey!

Since servicing technical debt is not a value-added activity for the customer, companies should desire to spend as little time as possible in this area. Based on the environmental factors I listed above influencing the growth of technical debt today, I don’t know if it’s possible to ever truly stay debt-free. However, there are some things we can do to avoid technical debt and to minimize the amount of activity required to service the debt in the future.

  1. Make it visible so the problem is not hidden – List technical debt as a category on roadmaps or backlogs. 
    • List items expiring or going end-of-life for support
    • Place an estimated dollar amount on each item (or each unit) – Show the debt as a liability 
  2. Stop and fix the problem – Make recurring payments to avoid a technical debt snowball
    • Service technical debt in like-manner as financial debt. Make recurring monthly payments 
    • Keep balance of debt to other backlog/roadmaps item to a specific percentage
  3. Standardize the task of removing technical debt – Take proactive measures to avoid technical debt
    • Apply vendor patches and security updates on a recurring schedule
    • Schedule upgrades in advance of vendor end-of-life

Go lighten your load. Dump some debt.

Onward and upward!

Photo credit: Alan Levine “Calling old Technologies” via creative commons https://flic.kr/p/q64isM