Media Query Source: Part 49 - InformationWeek (US digital magazine); Effective ways to tame technical debt

• InformationWeek (US digital magazine)
• Effective ways to tame technical debt
• Technical debt involves weighing trade-offs between short-term and long-term goals
• Collaboration is especially critical when the technologies used to build a product drive what the product can provide for customers

The query responses I provided to InformationWeek on February 7, 2025:

InformationWeek: What is technical debt? Is technical debt ever useful?

Gfesser: Technical debt is essentially the future cost incurred when prioritizing the short-term over the long-term when it comes to delivering technical solutions.

In other words, technical debt is kicking the can down the road, with the can representing something that could be done in the short-term but is postponed to a later date (or indefinitely if the can keeps getting kicked).

The future cost is similar to interest that is paid on financial debt, because regular payments must be made until the original debt is repaid.

Interest can take the form of instability in the system, and increased maintenance costs due to the hacked-in changes and lack of proper design, documentation, and / or automation.

Eventually, if the can keeps getting kicked down the road too long, default or bankruptcy may result. If technical solutions are still needed to solve similar problems at the point in which technical debt is tackled, expensive re-architecture or complete replacement will be the likely result.

I personally consider technical debt to be a subset of organizational debt, because technology is part of the business. And when a business offers technical solutions as products for their customers, technology is the heart of the business.

While technical debt always incurs interest, it also involves weighing trade-offs between short-term and long-term goals.

I've often used technical debt as a strategy in order to build products that meet functional needs, knowing that I'll likely need to revisit the trade-offs I've made at some point in future phases of the product life cycle.

For example, I may know that the scalability of the architecture will need to be revisited if customer demand ends up being higher than expected. However, it doesn't make sense to incur interest in the short-term if I already know it's likely that additional scaling will be needed in the future.

InformationWeek: Is there anything else you would like to add?

Gfesser: The danger of deliberately using technical debt as a strategy is that not all stakeholders will understand the decision process behind it or the implications of making use of it.

In my experience, best results are typically achieved when architects, and other technology leaders doing the building, work within product teams so that trade-offs being made always consider the product life cycle and any road map changes expected along the way.

This collaboration is especially critical when the technologies used to build a product actually drive what the product can provide for customers. Poorly chosen technologies can stifle the life of a product just like wisely chosen technologies can further the life of a product.