Debt is certainly a familiar concept for all businesses. It is the practice of borrowing now to pay back at a future time. Besides financial debt, many technology companies can also experience technical debt and feature debt. Both terms refer to decisions made during the product development cycle that may need to be revisited further down the road. Does it make sense for your business to incur technical debt and/or feature debt? Possibly. Read on to learn more.
With the exception of a house, car, and a couple of other major life purchases, most would agree that going into debt is generally something to be avoided if at all possible. Debt does give us the ability to realize a reward of some kind in the immediate term (perhaps an overseas vacation or buying a fancy outfit), but that debt needs to be paid back after the reward has been consumed or realized. Often the payback comes with a significantly higher cost, and at times, with unintended consequences in the end.
What is Technical Debt?
The term technical debt was coined almost 30 years ago by renowned programmer Ward Cunningham. It is used to refer to the accrued cost of short-term compromises made by developers during the hardware or software development cycle. These compromises are often made in architecture, flexibility, or quality – usually to deliver capabilities faster. The thinking is that the faster time-to-market will more than offset the cost to re-engineer/fix the systems or software later.
Customers can also incur technical debt on the systems they have purchased when they defer major and routine incremental upgrades.
The Benefits and Downsides to Acquiring Technical Debt
Since it’s pretty common, there must be a benefit to technical debt, right? Development teams will rationalize that taking a shortcut now, often in the form of hacks and workarounds, will get a solution to market faster and perhaps provide a coveted competitive edge to land a critical customer.
Further, development teams often acquire technical debt in small incremental ways, each independent or siloed decision contributing to a potentially expanding mountain. There may be times when these decisions are valid so companies can live to fight another day (i.e. stay in business), but they can often be offset by costly downstream penalties.
Likewise, customers can acquire technical debt to preserve capital in the short term on upgrades or maintenance contracts. In these cases, they may find that the deferred cost of upgrading/replacing may be higher due to compatibility issues, upgrade penalty costs, available talent to support older generations products, etc.
In an Accenture survey of more than 1,000 C-level executives, respondents said technical debt severely limits their ability to innovate (70%), makes them less responsive to changes in the market (69%), and slows the migration to new technologies (72%).
The most public recent example of customer technical debt is the government’s antiquated inflexible computer systems for processing pandemic-related unemployment claims. Many of these systems were programmed in the COBOL computer language, not used for new systems in almost 40 years. Despite this, approximately 43% of today’s banking systems and 95% of ATM swipes rely on COBOL code. The modernization of these systems will be costly indeed given that many programmers with COBOL skills are over the age of 70 now.
How to Pay Down Technical Debt?
An online search for the term how to eliminate technical debt, produces 22M results. It’s a big deal, for which the development teams are responsible.
Some development teams may feel victimized as their leadership and product management continually prioritize new features and allocate relatively little roadmap capacity for improving the codebase, while on the other hand blaming development for bugs, broken code, and the negative results of technical debt. Development must always own responsibility for maintaining or improving the architecture and code quality.
Interestingly, International Data Corporation (IDC) predicts that through 2023, coping with technical debt accumulated during the pandemic will shadow 70% of CIOs, causing financial stress, inertial drag on IT agility, and “forced march” migrations to the cloud.
There are recommended processes and tools to help manage existing technical debt. There are also design and coding disciplines that will help minimize the acquisition of technical debt in the first place. Some of these strategies include designing a modular flexible architecture, and a culture of code reviews and test automation. The starting point is creating a culture of technical debt monitoring, measuring, and proactive management.
What is Feature Debt?
In technology businesses, we may be fearful of technical debt, but there is another type of debt that is less discussed but by no means less lethal: feature debt.
Feature debt is the accrued cost, by the supplier, of the continuous addition of features and functionality without regard for the impacts to user experience or cost to maintain. Some call it feature bloat.
Suppliers incur feature debt when product managers, often in response from high pressure customers and sales teams, add more and more features to a product, without regard for the implications.
Customers can incur feature debt, though to a lesser degree, when they acquire a technology and customize it with hacks and bolt-on features not originally envisioned.
The Benefits and Downsides of Feature Debt
Feature debt may be the response to the need for agility, however, there can be downsides to this agility. Feature bolt-ons may ultimately need to be completely redesigned, bringing disruption to the user experience and pain to the customer. Features that may have been developed under pressure from a small number of customers carry incremental cost of testing with every release, resulting in high relative cost for low use.
How to Pay Down Feature Debt?
Product Management has full responsibility for managing feature debt. As the owners of the product requirements and how that functionality is prioritized for development on the product roadmap, Product Management has the responsibility for effective feature design and use. While short-cuts can be very alluring, there’s an expression I have always reinforced with my product teams: “If you have time to do it twice, you have time to do it right.”
This is where Product Management must:
- Say “no” to special requests for one-off features and maintain focus on the functionality beneficial to the largest number of customers. Consistently use a Value Assessment Framework and have the strength to explain the rationale for not including the ‘offending’ feature in the roadmap.
- Consider the feature in the context of the existing user experience (UX).
- Add telemetry to understand how customers are using your products and consider removing functionality that is not actively or effectively used.
- Increase the R&D budget if it’s determined that all features are indeed equally relevant.
We can pay down feature debt by allocating some percentage of product roadmap capacity with each release. According to the XaaS Product Management benchmark, a median of 30% of the roadmap is spent on incremental feature functionality and 12% on managing down tech debt and just 4% on telemetry and analytics. This suggests an opportunity to rebalance the scales.
Closing Comments
While it is best to avoid both technical debt and feature debt, sometimes it is the right decision to make in the moment for the right reasons and with proper assessment. If technical and feature debt must be acquired, I recommend keeping them transparent to the planning process. Just like a payment plan for regular debt, keep your technical and feature debt in check and pay it down a little at a time to avoid ballooning interest.