Technical debt is costly and can slow down innovation. I share my thoughts on how to find the right balance between keeping your code maintainable and still keep the competive edge.
What is technical debt?
Technical debt refers to the future costs and consequences of using quick or easy software solutions instead sustainable approaches, leading to increased maintenance and correction efforts later.
According to Mc Kinsey the cost of technical debt, in the U.S. alone, reached around $1.52 trillion in 2022. This may sound a lot, but it starts to make sense when we dive a bit deeper into the costs involved:
- Maintenance costs: increased system complexity and higher frequency of bugfixes.
- Development costs: Slower development of new features and increased time for onboarding people.
- Operational costs: reduced performance and increased infrastructure costs.
Besides these direct costs there are also hidden costs involved that are harder to calculate:
- Opportunity costs: missing marketing opportunities due to delayed product releases or missed market opportunities.
- Quality costs: customers moving to competitors because they experience issues with your product and lose confidence in the company.
- Financial costs: loss of company valuation due to its inability to innovate and maintain high product quality.
Let’s go for 0 technical debt.
When you read the paragraph above, you may feel a tendency to reduce technical debt to zero but that is highly improbable and even not desirable. The key to success is to find the right balance between innovation and technical debt. Software development is always a compromise between speed, costs, and quality. On one hand developers want to create the easiest to maintain code but on the other hand there are deadlines to be met and budgets to uphold. Good software developers understand when to incur technical debt for short term gains and where to avoid it.
Another reason for not going to zero is that today’s solutions can become tomorrow’s technical debt. Every day new tools and best practices emerge, existing libraries become outdated. Teams need to avoid the trap to be optimising forever or else you are optimising an outdated tech stack.
Lastly and to me the most important: systems grow and become more complex over time. This is a fact of (developer) life. Maintaining a zero technical debt practice will become impractical and cost ineffective.
What can be done?
Many things can be done to reduce technical debt but these 3 are the things I recommend doing first.
First, I recommend promoting a culture of quality and responsibility. The team must feel ownership of the code and understands long term benefits of managing technical debt but also understands the need to meet deadlines and business goals. To me this is one of the most important skills to have in software development and it demonstrates seniority in a programmer. Experienced developers should be the promotors of this behaviour and mentor the less experienced developers.
Invest in automated test coverage. Tests give developers confidence during refactoring, helps with designing the software architecture and detects issues early. To me it is common sense to have tests when developing but when the deadline comes near, test coverage is the first thing that drops off. Some developers create tasks to write tests afterwards, but I am not a big fan of it. Normally these tasks tend to be pushed down the backlog very soon and you need time to learn your code again when executing this task later. Test driven development (TDD) can be a good tool to use but I also recommend having a good balance between speed of development and test coverage. I normally do TDD for the riskiest part of the system and tend to skip it for less risky features.
Last but not least work agile, Agile? I hear you thinking we do this for decades, but then ask yourself how many times did you develop an MVP of a feature, test it, measure the outcomes, refine the feature and then do the cycle over and over until you reached the desired outcome? I think most of you work in “mini waterfalls” (believe me I did often) where we refine the scope upfront, cut it in small pieces so we can squeeze it into sprints, launch the feature with a big bang and fix bugs. The problem with this is that teams do not visit the feature’s code any time soon and when it is time to develop, most of the code has been forgotten. I am a big fan of the method Continuous discovery designed by Teresa Torres. In short Continuous discovery is a product development method where teams constantly gather feedback and insights through small experiments to validate their product decisions. By incorporating a continuous loop of user feedback, the idea is that teams develop products that fit their market needs. It provides short iterations and constant refinement of a feature and keeps the changeset contained.
To summarize balancing effectively balancing technical debt and innovation is essential for sustainable software development and long-term success of your organisation. The key lies in understanding that both elements require continuous attention and thoughtful management to drive growth and maintain competitive edge.