On New Year’s Day, chaos erupted at the Philippines’ Ninoy Aquino International Airport after a failure in the uninterruptible power supply equipment being used by the Civil Aviation Authority of the Philippines, triggering the technical problems that disrupted hundreds of flights and left tens of thousands of travelers stranded.
In December last year in the US, severe weather conditions caused thousands of Southwest Airlines flight cancellations and escalated into a complete meltdown of its flight system. It is blamed on the company’s failure to modernize its scheduling systems, relying only on older or deficient software that needs updating for several years.
These are recent and glaring examples of technical debt — the implied cost of technology’s failure to keep pace with customers and businesses, resulting in system breakdowns. The root cause of the failure may be neglects to perform upgrades or maintenance of the technology infrastructure, or poor software development that prioritizes speed over well-designed code.
The technical debt term traces back to Ward Cunningham, an American computer programmer, who wrote on his blog in 1992 that the serious pitfall for software development is “shipping first-time code” which is “like going into debt.” He was referring to prioritizing speedy delivery of software over perfect code, which could bite the organization using it in the future.
An often-cited example of technical debt is the Year 2000 (Y2K) problem. Most software developers in the 60s and 70s practiced saving precious memory by storing dates “73” instead of “1973,” which continued to be implemented for years, even as memory prices declined. Those programs became embedded into business operations and remained in use far longer than anyone had expected. When the year 2000 neared, thousands of businesses, organizations and government institutions realized that date calculations would result in massive system failures, necessitating them to undertake a frantic upgrade drive. The Y2K problem cost the world an estimated $100 billion, which could have been prevented.
Martin Fowler, author and technologist, categorizes technical debt into four different quadrants according to its causes: Reckless/Prudent/Deliberate/Inadvertent.
Prudent and deliberate. This is the most common source of technical debt. To get the software product to market quickly or a system to be operational to ultimately get more revenue, the technology team will usually choose a faster solution with lower development or build cost and shorter time, but the solution is not optimal and may only be temporary. But the team is aware of this with a detailed evaluation, and improvement plants in the future are in place.
Reckless and deliberate. The technology team knows that the current solution is not the optimal choice, but the business requirement is the first priority. Due to the urgency, there is no detailed analysis of the current solution which may lead to a huge possible impact on the legacy technical. The specific problems that arise may be unknown.
Reckless and inadvertent. This arises from the technology team’s lack of skills and experience, making them unaware they are causing technical debt. This could lead to unwanted issues which could be prevented with experienced developers and technologists
Prudent and inadvertent. This happens when a knowledgeable technology team applies best practices during the software development or infrastructure build, but inadvertently generates technical debt due to unseen coding or design mistakes. However, the team can identify and rectify the technical debt later due to their skills.
From these classifications, technical debt can come in many forms such as poor software code quality, insufficient software or infrastructure testing, lack of documentation, poor infrastructure maintenance and fast deployment of systems such as those remote work systems during the height of the pandemic.
Is technical debt bad? Just like financial debt, technical debt is neither good nor bad; it depends on the business needs and how technology and business requirements are balanced. Organizations need to ensure that technology teams are well-equipped and skilled to make appropriate decisions that balance technology and business demands. They, including business managers, should be aware of technical debt and its consequences.
The author is the founder and CEO of Hungry Workhorse, a digital and culture transformation consulting firm. He is the chairman of the IT Governance Committee of Finex Academy. He is a fellow at the US-based Institute for Digital Transformation. He teaches strategic management in the MBA Program of De La Salle University. The author may be emailed at email@example.com.