Introduction

Earlier this year, the President signed the MGT 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 $500M in Working Capital Funds (WCF) or self-fund their own WCFs to modernize legacy applications and repay them in the future. The reason for this approach is that existing appropriations from agencies are mostly consumed in Operations and Maintenance (O&M), forcing some agencies to borrow from revolving funds to support Development, Modernization, and Enhancements (DME). Part of the explanation may be due to the pace of technology evolution, new legislation, new sources of cyber threats, and heightened expectations from citizens. One of the major reasons for this problem is the “Technical Debt” accumulated in federal systems due to shortcuts taken during software development today results in future spend for fixing 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 of technical debt

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:

• “Let’s just copy and paste this code; it’s ok for now.”
• “The legislative deadline is coming up; just get it done!”
• “We know how it should have been implemented, but it’s too late now.”

 For unobservable clues, analyze your project metrics such as defects, productivity, and quality/age of code. Example clues include:

• Team productivity plateaus or decreases despite having a stable team
• Too many TODO and FIXME tags are present in the source code
• Use of old libraries such as Angular JS even when newer versions are more productive

Consolidating technical debt and making it visible

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 (“good” or “bad”) 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. For example, they may bypass 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 – accrued debt that you must repay at some point including effort to fix a debt item
• Interest – increased maintenance cost, development cost of new features, or employee turnover
• Interest Rate – 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. As you evaluate priorities, 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 (or interest rate) and find ways to chip at it (minimum payments). Make debt management an explicit release objective, and budget resources to repay it. For example, you can allocate up to 10% of available development time for unplanned/unscheduled code refactoring and cleanup work. Adopt team norms such that when anyone notices debt, they try to address it “just-in-time”, if possible. Occasionally, depending on the nature of debt, you may consider the following two strategies:

• Full Repayment – refactor or replace the code, library, framework, or platform to eliminate the debt.
• Debt Conversion – find ways to lower the “interest rate”. For example, replace costly customizations on old versions of low code platforms with acceptable out-of-the-box solutions on new versions.

Minimizing future debt

Although some debt in software solutions is unavoidable, we can adopt strategies to avoid “bad” debt and accrue “good” debt for business benefit:

• Definition of Done – Identify dos and don’ts as part of your initial standards of development. Educate customers and team members in estimation, execution, and “debt” management.
• Peer Review – Use software development techniques such as pair programming to make it harder for developers to take shortcuts since “someone is watching”.
• Process Tools – Integrate tools such as SonarQube in your CI/CD pipeline to identify issues with code complexity and test coverage.
• Awareness – Train team members in emerging technologies and make your customers aware of how to use “good” debt to their advantage and avoid “bad” debt.

Concluding thoughts

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 WCFs with minimal “interest”, they must act from Day 1.

About Authors

Viktor Pylypenko, Technical Architect, REI Systems

Viktor Pylypenko joined REI Systems in 2003 and has expertise in the design, development and modernization of complex large-scale applications for financial institutions and the U.S. Government. Mr. Pylypenko holds Bachelor’s and Master’s degrees in Engineering from National Technical University of Ukraine “Kyiv Polytechnic institute”

 Subhash Kari, Chief Technology Officer, REI Systems

Subhash Kari joined REI Systems in 2001 and has expertise in grants management, enterprise systems, and business intelligence. He has led the design and implementation of technology-based solutions for many of the largest grant-making and regulatory agencies in government. Mr. Kari holds Bachelor’s and Master’s degrees in Engineering and is a proud alum of Michigan State University.