Viewing Technical Debt from a Financial Perspective

What is Technical Debt?

Technical debt is the creation, either purposefully or not, of imperfect or unsound code which increases over time. Typically, technical debt is created one of three ways: shortcuts, accidents, or entropy.

Shortcuts are the most visible type of technical debt and the most predictable. Created out of the necessity to get a product to market quickly, shortcuts intentionally add debt to a codebase in exchange for expediency. This type of debt should be anticipated - it happens in almost all software projects - and therefore the time to fix these issues, before moving on to developing more features, should be included in project planning/planned for at the beginning of the project.

Accidents occur when the architecture of a codebase is unclear. Typically, engineers function under a “mental model” of architectural guidelines in code. When this model is incorrect, because of relationships breaking guidelines or additions from other teams, they can create cyclic dependencies that increase complexity and violate architectural principles; creating areas of the code that cannot be touched or changed without a “ripple effect” on other parts of the codebase.

Entropy in code happens when coding practices improve and older code written before these improvements contains artifacts of prior methods. While all code is intended to be future-proof, no code ever achieves that perfectly. Remediation for entropy-led technical debt

• Codebases have good code quality:poor architecture quality

• Introduced in codebases with a lot of changes

• Impacts of changes on architecture is not immediately obvious: architectural degradation happens without being noticed until later

should be added to the development schedule to be addressed as necessary.

How does technical debt affect business financials?

Before we can determine the cost of technical debt, it’s important to look at the impacts. The more technical debt found in a system, the more difficult it is to code in that system. Technical debt can present itself in

• Repeated code

• Highly complex code

• Cyclic file-to-file relationships

• Non-modular architecture

• Product bugs

Each of these outcomes of debt create a codebase that is more difficult to work in, which slows down engineers. Silverthread has calibrated statistical models to over 6,000 commercial codebases and has been able to determine that when working in source code with high code complexity, developers are three times more likely to introduce defects than when working in areas of low code complexity. When working in highly complex source code developers are 1/3 as productive as when working in well structured code. As we all know, time is money, and slowing down development leads to missed product launches, inability to keep up with competitors, and imperfect predictions of future capabilities. Technical debt also leads to a higher risk of downstream product bugs that make their way to the consumer. Releasing a product that gives the consumer a poor impression of your company is an expensive mistake.

The dollar value of these issues is typically hard to quantify, because while code slowdowns and downstream bugs may be visible, the exact cost of repairing them is difficult to predict. Discovering the value of a refactoring initiative can be broken down into 4 steps:

1. Understand the current state of the software

• Know how much it costs to develop software currently, and how long it takes to write a 1,000 line of code feature. This number varies depending on the area of the codebase in which each feature is written, the quality of architecture in each area, and the amount of development and activity each area sees

2. Plan a refactoring scenario

• Compare the state of the current codebase to how development time and cost would differ if the codebase was, for example, 20% more modular. By scenarios of codebase improvement, developers can determine the level of codebase improvement that would best fit the needs of your software.

3. Model the refactored codebase

• Once the ideal level of architectural improvement is understood, model the development of new lines of code in the improved environment. This gives you an apples-to-apples comparison with the current state of the system.

4. Compare the existing codebase to the refactored model

• From the model above determine the volume of change and the impact that change will have on development, risk and security. Using various business side inputs, including salaries, past costs of imperfect releases, and system security costs, translate these impacts into financial metrics. Time to refactor is measured in development team salaries as well as delay in current release schedules. Improvements are measured in recovered FTEs, money saved from preventing downstream bugs, and lessened risk of technical errors including security breaches.

Silverthread’s CodeMRI ROI Tool pulls these steps together in a streamlined format, quickly comparing multiple refactoring and improvement scenarios to identify the best option for your team. By translating the necessary software improvements into easily understandable economic gains, our ROI tool opens conversations between the technical and financial sides of the business, allowing for objective and informed decision making that is advantageous to the company as a whole.