Just as financial systems have financial systems have financial debt, technical systems have technical debt. Technical debt is a shortcut taken to help quickly launch a feature or meet an urgent deadline. When the shortcut is used, it is generally with the intention of revisiting the work later on to add the work that shortcut skipped.
As time progresses the technical debt increases. As an example, imagine purchasing a new computer for £1000 using a credit card. Each month the debt of £1000 is not paid back the credit card company charges you a percentage of the outstanding balance. So after a month you could owe £1010, then £1020.20 and so on unless you start paying off the financial debt.
Technical debt is similar, for example: a coder skips following an organisations coding standards so that the coder can quickly implement a new feature in the way they understand (which may, or may not cause a bad code smell). The code is published and the new feature is live. The coder aims to come back to the code and fix it whilst the it still makes sense in their head, but gets caught up on another urgent task.
Several months progresses, the code has not been changed and another coder needs to update the code behind the feature, however it doesn’t follow the coding standards expected. Variables are named in a non-sensical way and the code is poorly optimised. The new coder then has to spend time understanding the code, cleaning the code and maybe even refactoring the code before it can be updated to complete the new coders original task. This might also involve asking the original coder (using their time as well) for assistance, and chances are they don’t remember why they coded it the why they did. The time then spent resolving the original shortcut is generally greater than time saved by taking the shortcut. Now imagine this happening multiple times in a working week to multiple coders. Eventually more time is spent sorting out technical debt than creating new features or taking on new work.
You might be reading this and thinking, “ah, so tech debt is just a coding thing”. Sadly not. Technical debt can come in many ways including:
- Coding Standards – as covered in the above example.
- Poor Design – as in not mapping out processes and not designing, jumping straight into coding.
- Comments / Documentation – lack of comments / documentation, or out of date comments / documentation
- Dead Code – leaving old code or old files in place when they are no longer required.
- Over-Engineering – Building features / functions that are not required and may not even be used.
So why does technical debt occur? Many reasons including, but not limited to:
- Deadlines – most people have had those “urgent” deadlines that arrive out of the blue and generally as several other urgent deadlines are looming.
- Knowledge – if someone is not aware of the coding standards or business policies in use, how will they know to follow them?
- Tooling – having the right tools makes the job easier. Having the wrong tools makes the job harder and generally encourages work arounds.
If technical debt is bad, should it ever happen? Just as with financial debt, technical debt can be be incurred if its understood, is managed and if it’s paid back before it becomes too costly.