Product Technical Debt is something no product manager wants to talk about. The reason is that product technical debt is not sexy and does not include cool features. The fact is no one, except the internal teams, sees it, and even for those that work on the product, the concept of technical debt is hard to fathom.
So why is product technical debt a problem?
Let’s take our life as an analogy is a good Debt and bad Debt. Bad debt (such as high-interest credit card debt) is generally bad, and if it is too much, it could cripple one’s financial life. Even good debt (such as a mortgage loan) can be harmful if it is beyond the means.
Similarly, technical debt in a product or platform can drown and cripple an organization. Given the importance of the topic, here is an attempt to compile the concepts about the technical debt of products and platforms in an easily consumable way. This post is not an original thought, but a compilation of concepts and ideas from the giants in the field.
At the outset, it is critical to note that while a product manager is in-charge of the product/platform, the accumulation of technical debt is a combined sin of both the product and engineering teams and most blame may lie at higher echelons of the corporate hierarchy.
Irrespective of the source and responsibility, the scourge of product/platform technical debt is crystal clear and product management practitioners along with engineering managers have to take measures to mitigate and eliminate the deficits.
The Concept and Complexity of Product Technical Debt:
Ward Cunningham coined the term in the early nineties to describe the consequences of expedient decisions, poor software architecture, and bad coding.
Some firms get an output from SonarQube code analysis. Yes, this is important and very useful and will point out the coding defects. However, there is more to technical debt. The visible versus invisible factors that cause technical debt are essential to note. The following diagram by Philippe Kruchten is a powerful metaphor for how invasive the hidden elements of technical debt can be.
For the uninitiated, the term “Technical Debt” may cause them to think “It’s all those bad programmers in India and China or Ireland” or “It’s high time the technology folks got their house in order,” the truth is bad quality of code is just the tip of the iceberg. The majority of the technical debt in products and platforms happens way upstream – when the time to market or cost pressures compel architecture/technical teams to make suboptimal decisions.
Martin Fowler has proposed a technical debt quadrant to showcase the various types of debt elegantly.
The classic debt trap occurs when speed to market trumps everything. Cost pressures force people to take short cuts. Technology teams lack a holistic picture—suboptimal design decisions. And of course, terrible coding and testing. And this happens every day. Each subsequent rotation will compound the misery.
More than words, the following visual created by Israel Gat of Cutter Consortium captures the cycle and the spiral very well.
How technical debt happens is all over the place. From intentional to inadvertent. From lousy work to unavoidable circumstances. But knowing what the source of technical debt and their root cause are is essential.
Mindtree proposes another quadrant on the type of debt incurred by distributed agile teams.
The implications and impact of technical debt are pervasive and corrosive. Kenneth Rubin lists the following complications.
What are some of the best practices to incur less technical debt, and if you do incur technical liability, making sure it is structural and intentional, and more importantly, how to eliminate the deficit.
- Understand and accept the existence of the technical debt. Categorize the debt into various components. Quantify the technical debt, including assigning a compounding factor. Keep a running record of technical debt and the payoff schedule/plan.
- Acknowledge business and technical decisions that may lead to additional technical debt and create a payoff plan. Start with strategic upstream factors: Realistic business decisions, Better business definition, and Capability-based product/platform definition
- Design and Architecture have a significant impact on technical debt. Define a set of architecture principles, practices, standards, and norms. Compatibility to architecture guidelines and the right design decisions are paramount considerations.
- Reduce system/application footprint. The number of systems has an exponential impact on complexity, which in turn is a breeding ground for technical debt.
- Better ALM Practices such as Test-driven development (TDD), Test automation, Continuous Integration, Refactoring, and Pair programming
- Allocate budget specifically for reducing technical debt. If possible, piggyback on discretionary projects to address some of the functional debt items.
- Better governance practices. Obsolescence planning. Buffers for repayment. Application sunset.
How does your company deal with the concept of technical debt in products and platforms? Please share your thoughts.