Technical Debt – A phrase that brings shiver to any experienced engineer or software architect. In this article I’ll explore why it is so Evil and a few basic things you can do to stop it bringing your whole business to a go slow state.
(This is a follow-up article from my talk on Technical Debt at the recent Product Mavens Meet in Sydney)
What is Technical Debt?
Simply put it is the deliberate decision to NOT do something that would improve the quality or consistency of a computer system – in essence its decision to ‘fudge’ or ‘hack’ a solution when you really know you should be doing it properly. (If you don’t know you shouldn’t be doing it – you’ve got bigger problems just around the corner…).
In a way this is ‘visible’ Technical Debt, its an actual decision; the worst kind of technical debt is when engineers just end up creating it unawares, either by accident, false assumption or by being ‘stuck in rut’ as concerns software design.
Why is Technical Debt so bad?
Technical debt is bad as it leads to a degrading in the overall qualities of the system design, so it becomes harder to extend, enhance, scale or secure a system over time. It’s a ‘dead weight’ that if left to its own devices spreads like an insidious cancer throughout a system eventually choking it to death. It ‘saps’ your business ability to technically innovate and get back the full rewards for the effort undertaken.
The other big problem with Technical Debt is that it just keeps getting in the way of doing things right, its like a weight on your back that you cannot get rid of and it ends up restricting the way you think about how you solve technical problems…
Also Technical Debt tends to ‘bred’ more debt, as when you develop on top of it, that in itself becomes part of the Debt pile, as you would also have to fix the new software to get rid of the underlying debt – in this way over time it becomes harder and harder to change.
As hinted above, Technical Debt can also impact on your ability to operate secure and scalable systems. The fact that wrong things are often being done in the wrong places makes it very hard to suitably ‘segment’ a system security wise – plus it throws a right spanner in works when trying to ‘right scale’ different systems – you often end up with an all or nothing approach, which does nobody any favours.
Where do you find Technical Debt?
Unfortunately, it’s pretty much everywhere to a certain degree – anything that uses even slightly advanced technology will have some form of technical debt, as the cost of making things ‘perfect’ is very expensive it’s likely some corner was cut and that might be a piece of Debt; the question is whether it is in something critical or not and if people are willing to do something about it if it is indeed critical.
BTW Technical Debt can be very dangerous both to a business and to you as in individual – people have suffered serious injury or died due to technical ‘fudges’ or ‘bad assumptions’; in our increasingly technological world, this really needs to be managed as a going concern.
What are the signs of Technical Debt?
There are a few simple signs (or bad smells) that can indicate how bad your technical debt really is:
- Systems wearing multiple hats at once – Why write another service or API when you can just add onto one you already have? Mixing of environments that should be distinct resulting in systems that are tightly and often mutually coupled (this takes some real craziness to get like this, but it does happen).
- Front ends mixed in with your back ends – No division of responsibility, big security risk – where do you put such a system exactly?
- GOD systems – Like GOD objects, everything needs to reference a single system in order to work, no matter what; makes things fragile to any change.
- Data confusion – Who owns what? What is the real centre of truth and it is actually correct? What does it all mean (if anything)? Garbage In – Garbage Out…
- Same old, same old – Resistance to using new technologies (or even old technologies), its just too hard…
- Blame ping-pong – always somebody else’s fault.
- Security as an afterthought – if you are lucky! The assumption is its something that can just be ‘bolted on’ and everything is alright (hint: it rarely is…)
- This is the way we have always done it! – Limited mental blinkers, can’t see the congested & polluted forest for the trees.
- We need to get it done this way to meet the deadline/business need/priority…. Short term gain always wins against long term planning – its a team race, not a whipping contest.
- Missing out on known market opportunities – The business literally cannot move fast enough to benefit, so they do not try; or if they do try the benefit is marginal at best.
- Good people just leave – They recognise the rancid smell of technical debt when they see it, and they would prefer to do proper formal software development and work somewhere that actually adds to their CV. Plus remember how small the IT community is in Australia, you will soon become unable to hire any real talent if this keeps going on (then add in the recent changes to the Visa requirements and you have a true recipe for hiring hell, the ball is truly in the candidates court).
- What is a Technical Debt Register? – We don’t need one, we are fine in our ignorance!
If you have even just 3 of the above you are well on your way to Technical Debt hell!
Help! I’m in Technical Debt hell, how do I get out?
Well, you have made the most important step, recognizing you are infested with Technical Debt – congrats – I feel your pain!
There are a few simple things you can do to put an immediate stop to the rot.
- Demand that all technical projects come with a detailed architecture description – no more ‘responsive’ development. It’s alright filling in the gaps in the detail, but starting with a blank page (or no page at all) is good way to make more Debt without realizing it.
- Train your engineers to recognize Technical Debt for what it is and actually record away somewhere, in detail, when they have had to make some Tech Debt. You might find the effort of recording the Tech Debt is greater than doing it right (most engineers hate doing documentation with a passion, so use this to good effect).
- Review your Tech Debt register once a month and allocate 2 days a month to deal with it – the assumption here is that there will be a lot of little things getting in the way and you can knock them down one by one progressively. If you have something truly massive on your register, make knocking down into a project in its own right…
- Make the management of Technical Debt a management objective – track and measure, do not assume it will be dealt with.
If you find yourself swimming in debt, please get in touch, we have in depth experience in dealing with Technical Debt and helping business get out of the mire.