How to Overcome Technical Debt in IT Modernization Projects

Earlier this year, President Donald Trump signed the Modernizing Government Technology Act to allow agencies to invest in modern technology solutions to improve mission delivery and security while saving taxpayer dollars. Agencies can compete for the MGT Act money in a central working capital fund or self-fund their own to modernize legacy applications and repay them in the future.

The reason for this approach is that existing appropriations are mostly consumed for operations and maintenance needed to sustain existing systems, preventing some agencies from funding development or modernization. One of the major reasons for this problem is the “technical debt” accumulated in federal systems due to shortcuts taken during software development today that require future spending to fix the resulting problems tomorrow. It is imperative that every IT project manager in the government and every service provider pay attention to the technical debt in their solutions and manage it responsibly.

What is technical debt anyway?

Technical debt represents the cost differential between the resources and time needed to develop a software feature perfectly and those used to deliver the feature based on prevalent realities. During software engineering, some debt is unavoidable because of time-to-market constraints, unexpected external conditions, and evolving project conditions such as changing requirements. Such factors cause teams to take shortcuts such as ignoring documentation and skipping test cases for exceptions. These choices hide underlying quality issues that customers then pay for in the future through increased O&M costs. Furthermore, unmanaged debts over time can lead to stress, low employee morale, and scrapped IT projects.

Recognizing the Symptoms

Unlike with financial debt, for which you receive a bank statement, it may not be immediately apparent that you have technical debt because there are so few early signs and no explicit accounting for it. But, like a tip of an iceberg, there are observable cues in team conversations, such as “Let’s just copy and paste this code; it’s OK for now” or “The legislative deadline is coming up; just get it done!”  You also should analyze your project metrics such as defects, productivity, and quality/age of code.

Consolidating Technical Debt

When used properly, technical debt brings business and technical stakeholders to the same page with respect to quality and the cost of quality. To enable that, identify and track your existing debt, assign economic value to it, and make it visible. It can be identified using open communication through steps such as peer review, verification, and retrospectives. Use tools such as Jira to track the debt as backlog items with attributes such as debt type and estimates to repay the debt.

A “good” debt offers a strategic advantage to your business and is undertaken intentionally. For example, if you are developing an application for a one-time use, you don’t need to invest heavily in automation. A “bad” debt reflects poor choices made by project teams under constraints, such as bypassing test automation to pick up project slack to meet deadlines rather than negotiating with their customer.

To estimate the economic value of a debt and to aid in its management, draw upon terms from finance to achieve clarity amongst your project team members and customers. For example:

• Principal is the accrued debt that you must repay at some point including effort to fix a debt item
• Interest is increased maintenance cost, development cost of new features, or employee turnover
• Interest Rate is the level of impact on development, employee morale, and customer satisfaction

Repaying Technical Debt

As your debt is identified, work with your customer to plan its elimination, though you will likely discover that not all debt is worth repaying. For example, “good” debt taken intentionally on prototypes may not have to be repaid. During planning, select the debt with the highest priority and find ways to chip at it. Make debt management an explicit release objective, and budget resources to repay it. For example, you can allocate up to 10 percent of available development time for code refactoring. Adopt team norms such that when anyone notices debt, they try to address it “just-in-time,” if possible.

Although some debt in software solutions is unavoidable, you can adopt strategies to avoid “bad” debt and accrue “good” debt for business benefit by partnering closely with your customers.

To manage the technical debt responsibly, you need to create a shared understanding of what it is for your project, create and execute a debt elimination plan, and take steps to prevent unnecessary accrual moving forward. Remember, the longer you wait before repaying the debt, the less your team will remember how to do it. The situation worsens when team members leave, taking the knowledge with them. It’s not the original debt creators who pay the interest, but rather the current maintainers—just as the IT spend on federal contracts indicates. If agencies want to repay their loans to the working capital funds with minimal “interest,” they must act from Day 1.

Viktor Pylypenko is a technical architect and Subhash Kari is the chief technology officer at REI Systems. A more detailed version of this paper for highly technical audiences can be found here.