One of the biggest enemies a codebase will have is technical debt. It's inevitable and arrives sooner than you might think.
Defining technical debt can be a little elusive, after all, even the best maintained code bases will suffer from it.
At the most basic level, technical debt is the cost associated with choosing quick paths to software design and development challenges. However, even if the team is using best practises, technical debt will creep in. This is often as result of product changes which alter the principles that underpin the earlier design choices.
The consequences of technical debt can be anything from mild to crippling. The ultimate being the need to rewrite a codebase from scratch.
As the name suggests, debt needs repaying. Developers will need to spend considerably longer refactoring code down the line. The impact on a platform also includes stifling the scalability, longevity, stability and can hurt team morale.
There are cases were technical debt is reasonable such as the creation process of prototypes or proof of concept. In these cases the product is wildly changing and may never get beyond a first version. Here, investing early to prevent debt doesn't make much sense.
Here is my list of the prime causes:
- Cutting corners to release code quickly
- Bad design decisions due to poor engineering skills
- Bad design decisions based on lack of product clarity
- Poor coordination between software developers working on a codebase, amplified with more hands
- Lack of refactoring time built into software development process
- Using the wrong tools for the job
There are well established practices that will help you get on top of the problem and minimise the creation of more technical debt. The world of agile methodologies provides a treasure of riches in this department. I lean heavily on eXtreme Programming (XP) principles which contain some excellent programming best practices.
Despite being over 20 years old, the core principles of XP are as relevant today as they were when conceived. Implementing them fully takes time and they should be introduced gently with the buy in of the team.
The most relevant XP principles are:
- TDD (Test Driven Design) approach can have a huge impact on ensuring the right feature is delivered and relevantly is provides built in documentation. This makes it easier for another software engineer to come in and pick up the code
- Pair programming increases awareness of the codebase among software engineers and crucially creates better quality code. A well working pair will encourage each other to design and write better code
- XP encourages 'merciless' refactoring. Code should be refactored a several times before becoming being deployed into production. To work through existing technical debt, it's a good idea to put time aside for refactoring legacy code in each sprint
- Coding standards - The team should agree on and implement it's own coding standard which will make the code consistent in style and more readable
- By always striving for the simplest possible design, maintaining code becomes much easier
Happy to hear your thoughts on this article and your technical debt horror stories. Please also share your tips on tackling it in the comments below.
Please feel free to contact me should you wish some objective help in managing your technical debt.
Dan Jacobs is a London based interim CTO and product owner