Siam has been building products for founders since 2012. And if there is one thing that millions of hours of product development have taught us, it is this – time is the scarcest resource for leaders. Especially in today’s cutthroat startup environment, the cost of delay can be crippling, even fatal, to the aspirations of a business leader.
Amidst this relentless push to deliver products swiftly, there’s a lurking peril that often goes unnoticed until it’s too late – technical debt.
Coined by famous American computer programmer Ward Cunningham in 1992, technical debt may initially seem innocuous. It often starts as a shortcut, a necessary compromise to meet a pressing deadline, or an expedient solution to navigate a tight budget.
However, just like financial debt, technical debt accrues interest over time, and the price to pay can be steep. In this comprehensive write-up, we will delve deep into the hidden dangers of technical debt and how to identify it in your organization.
We aim to empower leaders like you with the knowledge needed to make informed decisions and be your ally in navigating these treacherous waters.
Understanding Technical Debt
Let me explain this in simple words. Technical debt is similar to borrowed money from the bank. You use the borrowed ‘principal’ to do something sooner than you might otherwise – like starting a business, for instance. But until you return that principal, you’ll be paying interest.
Similarly, when you are starting up, you build features with the intent to get them into the hands of your users quickly. In this pursuit of deadlines, product teams often cut corners in development. This creates a ‘technical debt’.
For product teams, the cost of rectifying technical debt includes both principal and interest.
Principal: The effort to address the primary technical debt.
Interest: The time and resources you spend on workarounds to navigate the problems created by technical debt. This includes the difficulty of introducing changes or the risk of the debt getting out of control.
Now, there is nothing wrong with quickly launching your product or having a ‘technical debt’. In fact, the basic principle behind MVPs (minimal viable products) is to get them out quickly in the hands of the user and get feedback to improve the product.
But, quite similar to monetary debt, technical debt is always looming. If you don’t pay back its interest in the form of maintenance or regular updates on user feedback, the end will come swiftly and take your product or entire business down.
Sources of Technical Debt
Now that we understand what technical debt is, it’s important to identify how it generally creeps into products. By identifying the sources, we can reduce the principal debt before it could get out of hand. Luckily for us, Intel, in its paper on Enterprise Technical Debt Strategy and Framework, has identified three ways in which technical debt creeps into product teams.
1. Deliberate or prudent debt is introduced when quick fixes are done to reduce time to market.
2. Accidental or outdated design debt is a result of systems evolving over time. When new capabilities are introduced, it takes more time to implement them because the platform may not scale – thus requiring significant refactoring.
3. Bit rot debt results from complexity introduced over time with many incremental changes and deviations from the original design and intent. In our experience, the bit rot debt is the hardest to fix as there are layers upon layers of code that need to be unravelled. So, it’s better to prevent this type of debt from occurring in the first place.
Five Common Types of Technical Debt
1. Code Debt
This is the most familiar form of technical debt. It occurs when developers write code that is suboptimal, lacks documentation, or doesn’t adhere to best practices. As code debt accumulates, it becomes increasingly difficult to maintain and extend the software.
2. Architectural Debt
Architectural debt stems from rushed or subpar design decisions. A poorly thought-out system architecture can hinder scalability and limit a product’s ability to adapt to changing market demands.
3. Design Debt
Design debt relates to user interface (UI) and user experience (UX) shortcomings. Neglecting the user experience can lead to usability issues, customer dissatisfaction, and increased support requests.
4. Requirement Debt
Refers to the distance between the optimal requirements specification and the actual system implementation.
5. People and Process Debt
Refers to people issues that, if present in the software organization, can delay or hinder some development activities. This can sometimes also lead to inefficient processes that may not be appropriate for current tasks.
The Real Cost of Technical Debt
As technical debt increases, it becomes costlier (time, money and other resources) to make changes and more difficult to respond to customers’ needs quickly. The figure below is from Jim Highsmith’s book Adaptive Leadership, which illustrates the nature of the problem.
Jim says that “the lack of adequate attention to address problems causes debt to increase until the cost of change skyrockets. And that cost comes in two flavors – the monetary cost and, even more damaging, the cost of delay in customer responsiveness. Customer complains, pressuring IT to fix the problem, which causes quick fixes that add to the debt – creating a vicious cycle that spirals ever-faster.”
From first-hand experience developing products for the last ten years, we have observed that the consequences of technical debt can either manifest swiftly or hit you in the long term when the ramifications could be even more alarming.
Immediate Consequences
In the short term, shortcuts and suboptimal decisions can lead to:
1. Sluggish Development
As the codebase becomes more convoluted and difficult to work with, developers spend more time troubleshooting, fixing bugs, and making sense of the tangled web of code.
2. Increased Maintenance Costs
Maintaining software riddled with technical debt can be a resource-intensive endeavor. Bugs crop up more frequently, requiring additional effort to resolve. The longer technical debt persists, the more maintenance resources it consumes.
3. Reduced Product Quality
In the pursuit of speed, product quality is often compromised. Features may be implemented hastily, leading to an inferior user experience, potential security vulnerabilities, and a higher likelihood of defects.
Long-term Consequences
While the immediate consequences of technical debt are concerning and irritating, the long-term ramifications deliver sucker punches that affect your business directly.
1. The Compounding Effect
It’s important to recognize that technical debt doesn’t exist in isolation. Each new feature or change is built on a foundation of technical debt that adds to the problem. This compounding effect can lead to a snowballing of issues that ultimately cripple your product development efforts.
2. Limited Innovation
As technical debt accumulates, it acts as a ball and chain, restraining your team’s ability to innovate. Resources that could have been invested in developing new features and improving user experiences are instead allocated to battling the technical debt monster.
3. Eroding Competitive Edge
In today’s fast-paced business landscape, innovation and agility are paramount. Companies that struggle with technical debt lag behind more agile competitors, losing market share and struggling to stay relevant.
4. Customer Churn
Technical debt often leads to customer dissatisfaction. Slow, buggy, or insecure software frustrates users and drives them toward alternatives. Customer churn can be a silent but deadly consequence of unchecked technical debt.
Measuring and Managing Technical Debt
Comparing technical debt to financial debt is one way to understand it. However, measuring technical debt isn’t as obvious as looking at your credit card bills or other financial account statements.
Over the past few years, the top tech companies in the world have made deliberate efforts to measure their technical debt. I will save you the time of going through hundreds of whitepapers to find out how they do it by saying one thing – it cannot be measured – not in the traditional sense with leading indicators. And most definitely, measures of technical debts that work for one company would not work for you.
Ciera Jaspan and Collin Green from the Engineering Productivity Research Team at Google published a research paper in IEEE recently about their experiments on quantifying technical debt at Google and how they failed to do it with traditional leading indicators and metrics. However, through their experiments, they derived insights into the key role that human cognition and reasoning play in driving developer productivity.
They observed that though they weren’t able to find leading indicators of technical debt thus far, we can continue to measure technical debt with lagging indicators or metrics that can be derived out of signs of bottlenecks of engineering teams and compare it with the ideal state that a system could achieve without technical debt.
Signs that Technical Debt is Becoming a Bottleneck
Customers aren’t the only ones who suffer the consequences of technical debt. Your friendly help desk staff will field more support calls, the software operations team will lose sleep patching the system all day, and management will get bad publicity, leading to the company losing its reputation among customers and peers.
Some of these metrics are measurable and can be used as lagging indicators that technical debt is taking over your company. Here are the lagging indicators you must watch out for.
1. Value Lead Time
Assess the end-to-end process of delivering value to users and observe how it evolves over time. This analysis can reveal friction points where technical debt intersects with other operational challenges.
2. Impact on End Users
Evaluate the latency within systems, customer onboarding duration, and the occurrence of quality issues. Delays and deficiencies in these areas are often traced back to technical shortcuts taken in development.
3. Developer Satisfaction
Pay heed to your developers’ grievances and concerns. Developers’ complaints can illuminate foundational problems in the technical infrastructure, enabling the prioritization of issues most affecting them.
4. Onboarding of New Developers
Scrutinize the onboarding process for new developers and gauge their satisfaction levels. Discrepancies or difficulties in the onboarding experience may uncover issues that long-term employees have adapted to but should not be ignored.
5. Degradation in Non-Functional Measures
Monitor non-functional measures such as runtime infrastructure costs, system performance, and availability. These indirect indicators can offer insights into the detrimental impact of excessive technical debt on overall business outcomes.
Clearing Debt, Fueling Innovation: Siam’s Way
Exploring the hidden dangers of technical debt has illuminated a critical facet of product development. Time, the scarcest resource for leaders, often pushes teams to navigate the perilous waters of technical debt in the pursuit of speed. However, as you’ve learned, this seemingly innocuous debt can accrue over time, hindering progress and innovation.
At Siam Computing, we’ve harnessed over a decade of experience to understand the delicate balance between expediency and the pitfalls of technical debt. By recognizing the sources and costs of technical debt and implementing sound measurement and management practices, we help you regain control of your product’s trajectory.
Our expertised product strategy consultants will guide you on this journey to ensure your product development is free from the encumbrance of technical debt and poised for innovation and sustainable growth.
If the need arises, we help you scale your product teams instantly with our own Swat team of product experts, developers, and designers to ensure your vision for a successful product aligns with a strategic plan to manage technical debt effectively.
Your vision is our mission – let’s build the future, one step at a time. Get a free consultation.
