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.
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 ☠️.
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.
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.
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.
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.
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 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.
[Wikipedia] Technical Debt
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.