What is Technical Debt?
This is a phrase used to describe the implementation of simple or poorly written code that will then need re-writing as a system evolves, and how it gets more difficult to fix that code as more time passes. You are in debt to this old code. The effort required to improve the system grows as time goes on, like interest on a loan.
You can help alleviate some of that interest if you start with a solid foundation. Proper planning is a good first step. Knowing where your software is and where you would like it to be, helps you build a product roadmap that can then help your development team architect the system appropriately. The can code while considering future expansions of the software.
In this article we will go over 5 practices to help you manage technical debt.
Technical Debt Left Unchecked
Product and engineering teams often have an unhealthy relationship with technical debt. Overlooked technical issues can lead to major bugs or outages, and they can substantially slow development over time. For their part, engineers often mismanage projects to address technical debt: they lack a well-defined direction, or a proper cost-benefit analysis.
Such mismanagement wastes time, and in some cases, creates even more technical debt than before. Left unchecked, this can lead to a breakdown in trust between product and engineering teams: if the product team senses that every technical debt initiative ends up taking a long time without a clear outcome, they will be reluctant to support such initiatives in the future.
5 Tips for a Healthy Relationship With Technical Debt:
1. Discover, Analyze, and Prioritize Technical Debt Initiatives
Discover, analyze and prioritize tech debt initiatives like any other product feature. Each initiative should have a well understood goal with clear benefit to end users, the priority should be agreed upon, and the drivers should bear responsibility for the success of the initiative.
2. Demand Justification
Demand justification for each tech debt initiative. The justification should be understandable by all stakeholders. Engineers should express their goals, challenge their own assumptions and evangelize the initiative to drive team-wide consensus. If this can’t be done, perhaps the initiative isn’t ready yet.
3. Maintain Laser Focus
Maintain laser focus and never lose sight of the user. Pursuit of technical goals such as modularity or code quality should always be weighed with respect to concrete needs of the end user. Even an activity like refactoring should be justified: it should lead to a reduction in bugs, increase in reliability, increase in performance, or development velocity. If the only goal is something like “event-driven architecture”, “functional programming”, or “micro-services” then try again.
4. When in Doubt, Use Brute Force
When in doubt, use brute force. If the desired coding style or architecture isn’t within reach, it is better to avoid it altogether and resort to brute force. Far too much time is wasted on half-baked abstractions, which are designed for the happy path and end up breaking down otherwise, leaving needless layers of indirection in their tracks.
5. Invest in Trust
Invest in trust. Build trust among product and engineering teams through transparency, collaboration, avoiding the “throw-it-over-the-fence” mentality. The engineering team should own the technical direction of a project, but they should work to keep this privilege by finding common ground with the product team and consistently delivering value to users.
Implementing these ideas won’t make technical debt go away completely, but it will help knock out some of the accrued interest. Software systems are iterative, meaning they constantly get improved over time. You code the best you can with the knowledge you have. Then you revisit that code as new information comes to light and make improvements.
Remember to plan ahead and collaborate closely with your team. You’re far more likely to succeed working together than against each other. The beast of technical debt is always looming, so follow the 5 practices above to ensure you don’t get swallowed whole.
Stay in touch with us for future blog posts (we will never share your information with anyone for any reason).