Technical debt can be a delicate subject to broach with clients paying for high quality work to be delivered within a strict time frame. It is understandable that assumptions of sloppy workmanship, poor time management or simple ineptitude might be made. Questions are likely to be asked. Why wasn’t this done correctly first-time round? Why do we have to revisit functionality that is already, well… functioning? In this article we will answer these questions and more, focusing particularly on technical debt relating to code.
So what is technical debt?
Technical debt is the idea that in order to deliver software on time, concessions must be made to postpone or delay certain aspects of the final vision. Generally speaking, it’s a knowing trade-off between quality and speed of delivery in which developers commit to simple, quick solutions over better, more time-consuming approaches.
It’s the daily struggle of programmers, developing the perfect, well-designed software that is future proof and will allow future enhancements and extensions to be added without too much rework, while simultaneously delivering according to the deadline or sprint. Much like we all might use a credit card to incur short term financial debt because it allows us to spread the cost over time, technical debt, if used prudently, can have significant benefits. That said, there is a threshold that cannot be surpassed without things going badly wrong. So, this balance is what needs to be kept in check. Deliver working software on a timely basis but keep the code as clean as possible in the interim.
The below image clearly shows the principle of technical debt, the more you ignore it, the more it will affect your capabilities of developing new features. Just like financial debt, you accumulate interest increasingly over time to the extent that normal operations are heavily affected.
In his blog post Martin Fowler describes the technical debt quadrant which defines 4 types of technical debt that may occur. Reckless, prudent, deliberate and accidental.
Deliberate – Reckless
This quadrant can come up in sprint planning or requirement conversations. An indicator this may happen is when developers start using the word “hacking”, which should trigger an alarm with the rest of the team. It basically means we know (deliberate) what to do here and how to achieve it but are taking huge risks (reckless) in the process. The key is always to avoid this quadrant, it may seem attractive but it’s the development equivalent of sticking a band-aid on a bullet wound.
Deliberate – Prudent
During sprint planning we can sometimes already identify the buildup of technical debt; this then immediately is added to the backlog for consideration. In JIRA we can easily identify this in the backlog via filters and have discussions on when this is going to be tackled, as many product owners understandably want to focus on new features.