Tech & Feature Debt Hygiene

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. 

Tech Debt is Big and it’s Impactful

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 to market faster. The thinking is that the faster time-to-market would 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 vendor upgrades.

Tech debt is big and it’s impactful. In a survey conducted by Foundry (IDC) on behalf of Insight Enterprises, reported that 86% of the respondents reported their organizations had been impacted by technical debt in the preceding 12 months, with big implications on innovation, SLAs and uptime.

A very public 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.

The Benefits and Downsides to Technical Debt

Since tech debt is pretty common, there must be a benefit to it, right?

Development teams will rationalize that taking a shortcut now may provide a coveted competitive edge or land a critical customer. 

Development teams often acquire tech debt in small incremental ways.

Tech debt can be unwittingly incurred in the absence of good code documentation.

Each independent or siloed decision contributes 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.

Paying Down Technical Debt?

 An online search for the term how to eliminate technical debt, produces 22M results. It’s a big deal, and for which the development teams are largely 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 tech debt monitoring, measuring, and proactive management.

Feature Bloat 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.

 Paying 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 and industry 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.

The Bottom Line

While it is best to avoid both technical debt and feature debt, sometimes it is the right decision for the right reasons with proper assessment. If technical and feature debt must be acquired, I recommend keeping both fully transparent to the planning process. Just like a payment plan for financial debt, keep your technical and feature debt in check and pay it down a little at a time to avoid ballooning interest.

I'd love to your stories where acquiring tech or feature debt was absolutely the right decision or, conversely, severely hurt you business.