How to Avoid Technical Failure by Recognizing the Consequences of Technical Debt

by

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 sort 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 build up of technical debt. Identifying technical debt can be difficult enough, but being able to communicate it to business stakeholders in terms they can understand is an additional challenge. If you look at an organization like Citi Bank, where there are 20 data centres, 50,000 servers, 350,000 laptops and desktops, 20,000 applications, and 12 billion transactions per month - how to 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, and an argument can be made that they shouldn't have to, but 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 bi-modal IT - by extending IT to support new business models in a given company's digital transformation, IT has began to split between fast and slow tracks. While the fast track is innovative and responsive to change, but the long term issues that haven't been thought through in the search for innovation are passed over to the operations team. But 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 quick as possible, whether it is an actual need or not. This will lead to further short cuts 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. And while most technical debt is not immediately visible, waiting until it is can be too late to fix it appropriately. 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.

To read the full post visit here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|