In the first three parts of this series we discussed topics related to defining, identifying, and quantifying technical debt. In this article we will discuss topics for consideration when planning a remediation initiative. The first thing to recognize before planning a payback strategy is that it is an ongoing effort. Paying back technical debt can be similar to a game of whack-a-mole. As you pay down debt in one area, new debt appears in another. This is a natural and unavoidable phenomena.
Change Creates Debt
Even if your company were to never write another line of code, you would continue to accumulate new technical debt. This is a result of change outside the technical environment. Technical debt accrues when the environment a system supports changes or our understanding of that environment evolves. The operating environment can be thought of as the collection of people, processes, technologies and external events that impact the application in some way.
Operating environments are in near-constant motion by their nature, and the applications that support those environments must be modified to accommodate that motion. Even if the environment internal to the organization remains constant, the external environment will change. Examples of external changes that impact an application could include the introduction of new technologies into the market, improvements in engineering practices, emerging threats, etc. This movement requires technical teams to incrementally adjust the application and refine those adjustments as they better understand the environment. Technical debt will accrue between the time the change takes place and when the application is modified to accommodate it.
Misalignment
When an application is first built, the teams who are building it have a limited understanding of exactly what it should look like. Development teams create an initial mental model of the application based on their limited understanding. Peter Senge defined mental models as “assumptions, generalizations, or even pictures of images that influence how we understand the world and how we take action.” The limited understanding of the environment leads to a fairly inaccurate initial mental model.
Therefore even if there are no shortcuts taken during the development process, there is a gap between the functionality the application provides and what’s really needed to fully support the environment. The Venn diagram in Figure 1 illustrates the typical relationship between the first release of an application, the team’s initial mental model of the environment, and the environment itself. As you would expect, the application is closely aligned with the mental model. However, neither is well aligned with the actual environment. Everything within the environment circle that is not intersected by the application represents technical debt.
As time passes, the development team gains a better understanding of the environment and the mental model improves. If the application is updated to reflect this improved understanding, alignment also improves and technical debt is reduced as in Figure 2.
This alignment is a temporary state. Once additional change occurs in the environment, things begin to look like Figure 1 again.
Prioritization
The value of the debt metaphor is its ability to frame technology gaps into a paradigm that any business person can understand. It can be challenging to get business partners to see the value of allocating resources to address something they may not see or fully appreciate. Putting technical shortcomings in terms of dollars and cents allows organizations to calculate the ROI on principal repayment. As a result, better decisions on where to invest technology dollars are made. Without the ability to demonstrate an ROI, convincing business partners to put off new features to payback technical debt becomes very difficult.
Let’s quickly calculate the return on the investment necessary to pay back the technical debt associated with the legacy application we discussed in Part 3. The principal amount owed on the debt is currently $160,000. If we were to pay the principal back today, we would avoid approximately $215,000 in inflation adjusted interest expense over the next five years. That gives the project to update the legacy application an ROI of 35%. Now we can compare that ROI to other initiatives and prioritize our inventory accordingly.
Repayment Options
The implications to paying off technical debt should be considered carefully. It is good practice to evaluate how end users of the technology will be impacted and choose a strategy to minimize disruptions. Some scenarios will be completely transparent such as refactoring poorly implemented code. In the example of our legacy application, however, there is a high probability of end user impact. Migrating platforms usually involves introducing a new user interface and changes to how functionality is implemented.
Even if end user impact is unavoidable there are usually strategies available to mitigate the effect. Taking an incremental approach can make the transition easier on the technology teams and end users. For example, if our legacy application uses a three tier architecture we might consider migrating the database and middle tier to the target platform and migrate the user interface last. This would afford us the opportunity to test two of the three tiers in a production capacity with potentially little impact to the end users. Additionally, if the user interface is fairly modular we may be able to migrate it incrementally as well.
In the next and final post in this series we will discuss ideas on how to govern technical debt effectively.
