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.
[1] Link: https://www.atlassian.com/blog/jira-software/3-steps-taming-technical-debt
It is important to understand the difference between prudent and reckless here. Everything we put on the backlog should be prudent, taking too many risks would be reckless and result in unforeseen consequences. Control in this quadrant is essential.
Accidental – Reckless
This quadrant is dangerous as it would mean the team doesn’t actually know how to do what is needed of them. Hence taking on debt without even realising. If this starts to happen, one must seriously consider the abilities of their team and, if no other solutions can be identified, look to add, replace or further train team members.
Accidental – Prudent
This may seem an odd quadrant but happens more often than one might think. During lengthy projects, it may be that your team discover an optimal solution to a specific challenge in the latter stages of development. This may occur because it is only in these latter stages that true requirements are properly defined. There is no real way to deal with this during the project without substantial delays, short of scrapping everything and starting from scratch. In the end, working products can be created, have a satisfied client and a happy team but still have this technical debt. In cases such as this, you must consider if it’s worth looking to clear that debt if all parties are satisfied, or simply to remember the lessons learnt during that project going forward.
A less common but still relevant occurrence is when business requirements change during the project. This can cause technical debt and is unanticipated or accidental. Imagine for example a mobile development where the design needs to change, this will make old code obsolete and as such incur technical debt. You may qualify this as refactoring, as the old code was not ready for this new feature (whether it was internally or externally created). Refactoring is how you handle the technical debt after it has been identified.
How about bugs?
Though expected, bugs are in a way technical debt (as in bugs can always happen in development so we should be prepared to deal with them when they do). How to manage the number of bugs in your backlog is a vast topic in its own right, from a technical debt perspective, let’s take a look at the created vs. resolved feature of JIRA.
The bigger the red gap, the bigger the technical debt from bugs is becoming. This overview really helps steer conversations around allocation of bug fixing.
Bugs are the definition of ‘expect the unexpected’, we expect them to occur but how, when and at what cost is impossible to predict. As such, additional technical debt may be incurred despite our best efforts to allow resources for bug fixing.
Communication and governance
Often, I have had discussions with developers on this subject, in some cases even pressing them to tell me if there might be any technical debt as some are reluctant to admit this to their team or manager. We must realise that technical debt is a burden the whole team needs to carry, not just a developer. Hence, it’s essential to communicate and register when and how technical debt is incurred.
Technical debt isn’t going to magically disappear, and it will accrue interest over time in the form of a slower and more expensive evolution of your product. It should therefore be part of your culture. Management must understand it, in best case scenarios measure it, plan for it, and commit resources for clearing it.
Need help with a technical debt strategy or other project management issues? Our team is ready to help. Contact us!
