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:
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:
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
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly