This summer, Southwest Airlines underwent various technical failures that led to the cancellation of 2,300 flights over the span of four days. This cost the airline approximately $54 million. Not much time had passed when a power loss at Delta led to a massive outage and British Airways experienced difficulties when their check-in systems failed. The purpose of outlining these failures is not to pick on the airlines, but to highlight that you don’t want to be in the headlines for reasons like the ones outlined above.
These sorts of avoidable disasters are partly due to aging systems that have become brittle due to budget constraints and deferred investments. Operational meltdowns like the ones we mentioned can also be attributed to a massive buildup of technical debt. Identifying technical debt can be difficult enough, but being able to communicate it to business stakeholders in terms that they can understand is an additional challenge. If you look at an organization like Citi Bank, where there are 20 data centers, 50,000 servers, 350,000 laptops and desktops, 20,000 applications, and 12 billion transactions per month, how do you begin to comprehend this amount of complexity, let alone explain it someone else?
Non-technical people often don’t understand the complexities associated with a given technology. An argument can be made that they shouldn’t have to, but that they should understand technical debt and the need to pay it back. This means that those working directly with technical debt also need to be able to communicate technical debt and its consequences adequately. The issue is that technical debt is often not immediately visible.
One of the many causes of technical debt is the rise of bimodal IT. By extending IT to support new business models in a given company’s digital transformation, IT has begun to split between fast and slow tracks. While the fast track is innovative and responsive to change, the long-term issues that haven’t been thought through in the search for innovation are passed over to the operations team. It can’t be forgotten that technical debt must be paid back.
Another cause of technical debt is the need to get to market as quickly as possible, whether it is an actual need or not. This will lead to further shortcuts and the creation of more liabilities.
Technical debt is, therefore, the cost that arises due to working to complete unfinished tasks that arose from a drive to be Agile and innovative, or from lack of funding. While most technical debt is not immediately visible, it might be too late to fix it appropriately if you wait until it is. When technical debt goes unpaid, it compounds. Every time you try to enhance a feature without fixing those underlying issues from technical debt, you will be adding inefficiencies, complexity, and cost to a project. Ultimately, you can end up with consequences just as severe as the technical failure we described at the start of this post.
The first step to going about paying back technical debt is by making it visible and recording it in the repository, then making a report with budget priorities on how to resolve the debt identified and recorded.