Introduction
As a business executive, have you ever wondered about the impact of Technical Debt on your business? Over the years, I have had the good fortune to actively work as an IT practitioner and trusted advisor. Through my professional journey, I have come across countless requirements for new applications and systems, often emerging from a panicked response to technologies that have reached their limits. In these difficult situations, stakes are high, pressure to deliver is great, and project execution requires talent and patience.
Consider the case of our consulting firm creating accelerated proposals to address greenfield situations where technology had never been applied to solve a problem (the telltale sign of a “we have always done it this way” syndrome that affects many businesses). Or consider the critical situation of helping clients address system outages due to unsupported or antiquated environments. To mention a few: mission-critical Oracle databases running on antiquated HP/UX Itanium-based hardware; Infoprint™ jobs executing on ancient versions of IBM i operating systems; ABEDing spaghetti RPG III code that would make you believe that punch cards were still the current input method of choice. Situations like these are the result of technical debt that has not been managed. Let’s define it further.
Defining Technical Debt
A Wall Street Journal article by Deloitte WSJ[1] states that “Technical Debt“
“… refers to the accumulated costs and long-term consequences of using poor coding techniques, making quality/time trade-offs, delaying routine maintenance, and employing other sub optimal IT practices in the enterprise. Those kinds of quick fixes may lower costs in the short term or keep software development and implementation projects on schedule, but they can also cause serious problems down the road if left unaddressed. Specifically, they may lead to application outages, security vulnerabilities, and increased maintenance costs.”
This definition points to a cascading set of side effects: outages, vulnerabilities, and higher maintenance costs. But is Technical Debt only about code? Did you know that hardware can also slow down business and industrial processes? Take the example of a medium-sized family-owned heavy equipment manufacturer that still used multiple manual steps to tag and track equipment as it flowed through its manufacturing process. Specifically, consider the lack of well-established technology such as barcoding — the result of postponed technology investments. Cycle times were elongated by the multiple manual steps that were required on the production assembly line. Old equipment (ancient by today’s standards) introduced system incompatibilities that made integration with barcoding technology, RF, and wireless networks challenging.
Technical debt in practice manifests itself in a broad set of ways: software, hardware, organizational structure, and even manual processes. Often, status quo business processes (the way things are done) were born in a time when technology could only do so much in terms of automation. Today, however, technology has evolved to the point that it has facilitated the opening of a broad spectrum of possibilities. This has allowed analysts and business leaders to imagine entirely new ways to operate — ways that are more profitable and efficient. Modern technology has allowed disruptors such as Airbnb, Uber, and& Amazon to come to life, thrive, and ultimately dominate. When technical debt is present, regardless of its form, it must be addressed because it has various implications for your business. In the following section, we will point out a few of the negative ways in which technical debt affects how businesses operate and how they are perceived by employees, their clients, and other parties that interact with them.
How Technical Debt Hurts
Spells death for innovation
Technical debt represents business friction. This means that time, money, and significant effort are spent doing things that could otherwise be applied towards advancing the business and creating a greater level of innovation. Companies that are known for innovation can maintain stronger and longer-term relationships with customers through continued thought leadership, better products, and industry recognition.
Invites disruptors
If performance is slow and innovation is nonexistent, competitors find openings for disruption. They will address those shortcomings that otherwise could have been filled by simple evolution of the business and core competencies. Technical debt should be seen as a significant contributor to the possibility of disruption by competitors who often strike when things are the most dismal.
Creates operational and development toil
Since technical debt is inherently a force of friction, attention often is not paid to processes improvement. As a result, both technical and management staff are often consumed with various forms of firefights addressing operational challenges. They are engrossed in development toil; products evolve slowly and digital transformation and the invention of new software assets stall or proceed very slowly. Lack of market-facing news goes unnoticed by customers and business partners alike.
Scares away new talent
Technical debt can have a serious impact on hiring. New talent will easily identify organizations that have fallen behind on technology adoption. Stale technology footprints are unattractive and offer very few signs for career growth and technical excitement. For this reason, companies with the least amount of technical debt are most likely to be able to acquire and retain new talent. An organization that can replenish its engineering talent inherently replenishes the skill sets which in turn fuels innovation.
Creates fragile systems
On a technical level, when systems have become stale and neglected, they also become fragile. This leads to outages, reduction in reliability, and sub-optimal performance. While to a conservative mind the lack of change may be perceived as a good way to provide stability, once a critical level of technical debt has accumulated, a threshold is crossed where engineering teams can no longer maintain systems with agility. Software systems are always part of larger ecosystems and frameworks that are constantly evolving, often at the expense of long-term backward compatibility. Critical updates and software improvements are inherited when software artifacts regularly update the underlying frameworks they are built upon. However, when the foundations get too old, updates become difficult to apply and the problem starts to compound. Missing out on updates makes it difficult to deliver superior user experiences to both internal clients, IT users, and most importantly, customers.
Creates a self-fulfilling prophecy of mediocrity
Slow and inadequate customer and business responses ultimately provide a negative feedback loop into the software development processes that enterprises follow to build technology assets. When technical debt is accepted, cultural IT stagnation onsets. This is a condition where teams are unmotivated and competitive drive (the good kind) begins to disappear. Team performance self-adjusts to the bare minimum required to maintain the status quo and the drive to innovate withers away. From an engineering perspective, designs and architectures are not revised. Hard problems are left on the backburner. When new system features are finally delivered, they are usually bolted on with little thought to how changes will impact future quality, system performance, and maintainability. Systems morph with little elegance into large complex systems with little modularity and coherent engineering. “Feeding the Monolith” becomes an acceptable practice. The cycle continues and the world of customers eventually recognizes mediocrity.
Impact on Agile Project Management
As development teams and operational staff are consumed with running the daily activities on inefficient systems, future development is always impacted. Technical debt always finds a way to rear its ugly head. It severely impacts project planning and execution. Timelines become stretched. Tasks are either missed or incorrectly estimated. In the worst cases, shortcuts are taken to make up for delays. Shorter testing cycles are seen as a way to make up time. Quality control suffers. Today, modern software and hardware systems follow agile methodologies to course-correct, adapt to new requirements, and deliver value more continuously. When technical debt becomes the norm, a culture of agile processes struggles to take hold.
Conclusion
So, what is the solution? How can technical debt be avoided or addressed before it becomes too extensive? The answer is simple: Organizations must build an engineering and operational culture that systematically rejects technical debt. To avoid technical debt, enterprises need to have a clear measurement of it.
Systems are like well-oiled machines. They require tender love and care. Imagine driving for thousands of miles, repeatedly ignoring the check engine light or pushing off oil changes. Would we do that? Most likely not, for we all want to avoid a vehicle break down. Instead, we pay attention to our vehicle status and get a tune-up when needed. Similarly, technical debt needs to be managed. It starts with having a clear and continuous understanding of an organization’s technical debt posture. It requires a cultural mindset that measures operational risk through timely assessment and planning. When technology changes, enterprises need to evaluate the impact of inaction and slow adoption. When will things break down? What is the risk-reward calculus? What is the true impact on the business and its reputation? What signals that are being sent to the market and competitors? How does it affect the ability to hire strong talent?
Managing technical debt will inevitably require continuous and phased investment. In most cases, phased investment results in a lower overall total cost of ownership transition when the time comes. Inaction instead will likely result in irrecoverable productivity, anemic innovation and growth, and disruption.
One thing is clear: Not many business executives have evaluated the true impact and total cost of technical debt. Their top priorities are often conservatively focused on maintaining operational continuity to support the business and controlling costs rather than exploring how a technology refresh — even a minor one — could create new business opportunities. In some cases, the persistent belief that IT is just an expensive cost center leaves the idea of IT innovation as something that applies just to young startups, not “well established” operations. All companies need to be aware of the need to adapt, predict, and be ahead of the next business cycle. There is only so much room for Technical Debt. Our advice? Migrate to Modernize.
About the Author
Michael “Mick” Bisignani, a professional technologist, held CTO and IT director positions. In his spare time, Michael aspires to become a burgeoning chef. You can follow him on Instagram @micksterct to tempt your taste buds.
References
[1] “How to Calculate Technical Debt”, Wall Street Journal, CIO Journal – https://deloitte.wsj.com/cio/2015/01/21/how-to-calculate-technical-debt/ . 21 January 2015
