If you have ever been part of a software development project, chances are that you have experienced the consequences of technical debt.
Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now, instead of using a better approach that would take longer.
In other words, technical debt conceptualises the tradeoff between the short-term benefits of rapid delivery and long-term value.
Taking shortcuts to expedite the delivery of features in the short term incurs technical debt.
Similar to monetary debt, if technical debt is not repaid, it can accumulate “interest”, making it harder to implement changes. This causes additional cost and rework over the software lifecycle.
Understanding and managing technical debt is an important goal for many teams, and Coletiv is no exception.
Technical debt can cause many side effects and unplanned work is one of them. Before digging into the relation between both topics. lets distinguish between planned and unplanned work.
Planned work is what was planned on being done. Usually, very detailed and specific tasks, that take into account the resources available (e.g.: time).
Unplanned work is what prevents you from doing the actual work you have planned to do.
In this article we are going to approach the relation between technical debt and unplanned work, as well as giving some possible solutions to tackle and reduce technical debt.
Technical Debt and Unplanned Work
A big problem with technical debt, is that it will ensure that the only work that gets done is unplanned work.
You might be thinking how can this be true?
Have you questioned yourself how many times does a proof of concept ended up in production, and you have to interrupt what you planned to do because it isn’t working anymore?
How many times a quick and dirty code patch 🔨 ends up not being refactored, causing failures in the system and you end up pausing everything you were doing to fix it?
In the end, these quick and dirty fixes led to unplanned work that forced you to stop everything you have planned to do!
Unplanned work has another side effect. When you spend all of your time firefighting 🚒, there is little time or energy left for planning.
When all you do is react, there’s not enough time to do the hard mental work of figuring out whether you can accept new work. So, more projects are crammed onto the plate, which means more multitasking, more escalations from poor code, which means more shortcuts. Around and around we go, sucked into the capacity death spiral ☠️.
How do we tackle Technical Debt? 🤔
In order to reduce the amount of unplanned work that your team has to deal with, we need to tackle the root problem that caused it in the first place: technical debt.
Preventive Work
We strongly suggest our teams to dedicate a certain percentage of effort to preventive work. And by preventive work we mean: refactoring, creating proper documentation, reducing code complexity, reduce compile times or whatever task that helps increase the code quality, the speed and the happiness of the development team.
Properly elevating preventive work is at the heart of programs like Total Productive Maintenance (TPM), which has been embraced by the Lean Community. TPM insists that we do whatever it takes to assure machine availability by elevating maintenance. Improving daily work is even more important than doing daily work.
It almost doesn’t matter what you improve, as long as you’re improving something. Why? Because if you are not improving, entropy guarantees that you are actually getting worse, which ensures that there is no path to zero errors.
You might be thinking “yes! yes! all your code is bullet proof and you never take shortcuts and… 🗣”. Don’t get me wrong, sometimes we trade quality for velocity, and that’s fine! As long as the team documents all the shortcuts taken, creates follow up tasks and understands that they will have to pay the technical debt back in the near future.
Throw less at the problem
From our experience, when a product tries to do too many things, technical debt tends to be created.
When a project isn’t working, the natural inclination is to throw more at the problem. More people, time, features and money. All that ends up making the problem bigger. The right way to go is the opposite direction: cut back.
Being able to take needless work out of the system is more important than being able to put more work into the system.
Good and Bad Technical Debt
While technical debt can have terrible consequences, it is not always as menacing as it may sound. You can look at it as part of an overall investment strategy, a strategic software design choice.
If you find yourself spending all your time dealing with debt or you reach the point where you cannot repay it, you have incurred bad debt. When you borrow or leverage time and effort that you can and will repay in the future, you may have incurred good debt.
If the software product is successful, this strategy can provide you with greater returns than if you had remained debt free. In addition, you might also have the option to simply walk away from your debt if the software is not successful. This dual nature of technical debt — both good and bad — makes it confusing for many project stakeholders.
We should never take on technical debt on purpose, and we should pay it back as soon as we know how. Also you should always consider doing less, or at least make a pause and analyse if a certain feature is actually so important for the overall goal you are trying to achieve.
References
Managing the Consequences of Technical Debt: 5 Stories from the Field
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
[Wikipedia] Technical Debt
Thank you for reading!
Thank you so much for reading, it means a lot to us! Also don’t forget to follow Coletiv on Twitter and LinkedIn as we keep posting more and more interesting articles on multiple technologies.
In case you don’t know, Coletiv is a software development studio from Porto specialised in Elixir, Web, and App (iOS & Android) development. But we do all kinds of stuff. We take care of UX/UI design, software development, and even security for you.
Top comments (2)
great article!
Thank you, George! We appreciate it!