Introduction
In a recent roundtable hosted by OB Collective, several Chief Technology Officers (CTOs) gathered to discuss the ever-pertinent issue of technical debt. The term, coined by software developer Ward Cunningham, refers to the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. As technology evolves, so does the complexity of managing this debt. Here are some key insights from the discussion.
What is Technical Debt?
Technical debt can feel like a barrier to further development. It often arises from temporary solutions or product advancements that are not revisited for optimisation. It was discussed that while low-code solutions can accelerate development, they are also a quick way to accumulate technical debt. Additionally, old work that is no longer strategic can hinder rapid development, acting as a significant obstacle. Importantly, technical debt is not always about code; it can encompass architecture, processes, documentation, and more.
Key points on technical debt include:
Temporary Solutions: Often become permanent fixes, leading to long-term issues
Product End-of-Life: Legacy products or projects that are no longer in active development can still hold crucial system components.
Complexity: Building reliable systems can introduce unnecessary complexity
Financial Implications: Upgrading and maintaining old systems require significant investment
Recognising Technical Debt
Identifying technical debt is crucial for managing it effectively. The CTOs shared several indicators:
Data Schemas: When it becomes difficult to map or understand data models
Engineering Estimates: Unexpectedly high-time estimates that are coming back from your engineers
Tech Debt Roadmap: Every company should create one to track and manage technical debt
Heatmap of Bugs: Monitoring bug reports can help visualise areas with high technical debt
Areas of Avoidance: Noticing where strong engineers hesitate to work can highlight high-debt zones
Getting Time to Address Technical Debt
Addressing technical debt requires buy-in from stakeholders. Strategies discussed include:
Building into Estimates: Integrate technical debt management into project estimates
RICE Score: Use the Reach, Impact, Confidence, and Effort (RICE) scoring model to highlight risks and prioritise debt management tasks
Tying into Metrics: Link technical debt to key performance indicators such as Velocity or Change Failure Rate to demonstrate its impact on productivity and stability. Weakness in your DORA metrics may
Actually Addressing the Debt
Once identified, addressing technical debt can follow different approaches:
Preventative vs. Remediation:
Preventative: Involves practices like code reviews, automated testing, and good documentation to avoid or minimise debt accumulation
Remediation: Focuses on fixing existing debt through various methods.
Subclasses of Remediation:
Tweak: Minor adjustments to improve functionality
Correct: Significant fixes to address root problems.
Deprecate: Phasing out outdated components.
Do Nothing: Sometimes the cost of addressing the debt outweighs the benefits, and it may be prudent to accept it as is.
The Hidden Costs of Delaying Tech Debt Management
There’s a Charlie Munger quote: “A company that needs a new machine tool but hasn’t bought it is already paying for it in lost productivity and inefficiency.” Similarly, delaying the management of technical debt incurs hidden costs that can impact the company’s overall performance.
Minimising Technical Debt
Preventing technical debt from accumulating is as important as managing existing debt. During the roundtable, we discussed some preventive measures:
Testing: Rigorous testing to catch issues early.
Quality Assurance (QA): A strong QA team that understands business requirements.
Vendor Selection: Choosing the right vendors to avoid compatibility and integration issues.
Engineer Retention: Good engineers prefer working on clean, well-maintained codebases, and excessive technical debt can drive them away. Similarly, engineers that expect to support a codebase for a long time should logically have more ‘skin in the game’.
A heat map of bugs and issues can help monitor the state of technical debt, providing a visual tool to prioritise areas needing attention.
Conclusion
Technical debt is an inevitable part of software development, but with careful management and strategic planning, it can be controlled. The insights from our CTO roundtable provide valuable guidance on recognising, tackling, and minimising technical debt. By staying vigilant and proactive, organisations can ensure that technical debt does not hinder their growth and innovation.