The “triple threat” part two: Technical Debt
Remember our client with the mission-critical software which has failed. The triple threat Foxsoft have identified as maintenance (or a lack of it), technical debt and documentation (or a lack of that) is what will bring you down. Here we’re looking at the second of these.
The second of our three threats is Technical Debt, which is best understood using the analogy of a payday loan. You’re halfway through the month and you’ve run out of cash (an unfortunate reality for far too many people). Because you still need to buy provisions for the next two weeks, you take out a loan, safe in the knowledge that you’ll pay it off when you’ve been paid at the end of the month. Problem solved.
Except you’ve not really solved the problem at all; you’ve simply pushed it into the future.
In some instances, this can be completely justified. Maybe you’ve had a one-off unexpected expense and are a little short to cover it this month, but know that come payday, you’ll be back in the black, and able to pay off the loan in full without consequences going forward.
But other times, things are far more serious, as the reason for this loan is a lack of cash due to the interest accrued on the loan taken last month, which in turn was needed to help pay the prior month’s loan, leaving you with less and less cash each month as any money you might have otherwise saved gets eaten by the ever-increasing interest payments.
Technical Debt is the same concept, but instead of pushing financial problems into the future, you’re pushing technical problems into the future.
Technical Debt is the result of decisions that knowingly, or unknowingly, are not in the interest of best practice, often made to obtain a short-term gain. For example, a developer could be under pressure to release a new feature by a certain date, so they take short cuts in the implementation to get it out of the door in time.
In an ideal world, they’d be able to immediately return to the code in question and refactor it, fixing the problems and firming up its stability ready for the next release. But stakeholders rarely understand the purpose and importance of refactoring, and so unless there is an obvious problem with a feature as a result, they will often pressure the development team to move onto the next feature.
This can result in one of three outcomes:
- Nothing happens: congratulations, you’ve managed to avoid a disaster
- The poor code leaks into other parts of the app or piece of software
- The app/software critically fails, often at the most inopportune time
If you’re lucky, nothing bad (or at least, too bad) will happen. If the app or piece of software is small and simple enough, the interest accrued by the technical debt is easily written off. But I’m willing to bet you’re not going to be lucky, and instead, at the very least, will suffer from the second outcome of the poor choices leaking into the rest of the app.
Please don’t misunderstand, I’m not talking about some type of sci-fi world where the code gains sentience and spreads across the app like a virus (yet ????). Instead, I’m talking about the very real outcome of existing choices within codebases influencing future choices, and how bad code begets more bad code.
This is often because of developers trying to work around the existing technical debt, or simply not understanding what something does due to lack of documentation (our third threat, which we’ll come back to in the next article).
At best, this makes future code more complex than it needs to be, resulting in more time being required to implement future features, slowing down the release rate. But at worst it can lead to the very real chance of our third outcome – that of a critical failure – and nobody wants that.
Therefore, Technical Debt is our second threat and is something which we explicitly set time aside to address, because as the popular phrase states, a stitch in time saves nine.
We’ve looked at lack of maintenance and technical debt as threats to software, often mission-critical. In our next article, we’ll look at what happens when you lack proper documentation.