Technical Debt is unavoidable, indeed sometimes it’s a necessity in IT. In case you don’t know what technical debt is, let me describe it.
Defining Technical Debt
Technical Debt is the notional or implied cost to a business or project of implementing a non-optimal solution or failing to fix an underperforming or buggy system.
That one sentence encompasses a huge variety of circumstances so let me be more specific.
Non-Optimal Solutions
Hang on a minute though, why would you implement an imperfect solution?
It is a fact that no solution is perfect and comprises a series of decisions and compromises. That in itself does not imply technical debt in all circumstances but often does.
Even very simple systems can accumulate technical debt. One technology or suite of technologies rarely meets the needs of a project perfectly and that fit changes over time – either through evolving demands placed on a system or changes in surrounding technologies.
No business stands still so the systems it relies on change over time. We tolerate technical debt in systems for a number of reasons:
“The latest new tech stack is just on the horizon, let’s develop using that!” – Noooo! Don’t do it, working at the bleeding edge of technology is exciting and stimulating for developers but using emerging tech in production systems can extend development times and give a dreadful UX because of bugs inherent in them. Your customers don’t care about the latest pre-release version of the DB you chose because you thought it was cool, they want the system to work first time every time and to be stable.
Wait until a technology matures enough that taking the step to adopt it makes sense. Plan and write solid code that can accommodate what you might use down the line and accept that this technical debt is the planned and the result of a considered and reasoned development path.
“The customer wants it now” – Yes, the best commercial reason for developing systems with built-in technical debt. Your developers will howl with pain now and in the future there will be a lot of shaking of heads “Why did we do it like this?”. The answer of course is commercial reality customers pay the wages.
“If only we’d known” – Whether it’s withdrawal of a provider’s service or a hitherto unheard of development framework that supersedes the one you chose two years ago there’s no solution to this one. Unless you have a crystal ball, and those are in very short supply.
“Who’s idea was it to do it like this?” – We all make mistakes, pick the wrong solution or find the requirements we were working to weren’t quite accurate.
Mitigating Technical Debt
The key take-away is this, acknowledge that technical debt will happen, plan for it as best you can and know when to deal with it.
1. Accept Technical Debt as reality.
2. When possible plan your Technical Debt so the inevitable fix is as painless as possible.
3. Evaluate whether now is the time to fix it – will it wait or will further development or delay compound the problem.
4. Is the Pain of fixing it more than the pain of tolerating it?
5. Admit when enough is enough and commit to fixing Technical Debt.
Ultimately there comes a time when the cost of carrying the technical debt exceeds the cost of fixing it.