A Hidden Burden
In IT, technical debt is a debt that you incur every time you take the easy path and avoid doing the right thing which lets the quality of your IT deteriorate over time. Just like a credit card, doing something for short term gain without regard to long term indebtedness, ends up hurting you in the long run.
With all debt, you have to pay interest. At first, it’s easier to pay the interest payment and continue on carrying the principal. Over time, because you have allowed yourself to get into the debt habit, your principal grows as does your interest payment. What does an interest payment of technical debt feel like? It’s felt through lost time and paying out money to fix your infrastucture and/or software or you have to do additional testing that ordinarily you would not.
It’s in the Code
Technical debt from software code comes in the form of code quality. If your code is easy to maintain, can be tested automatically, quick to modify, and documented you have little to no debt. If you release software with known bugs, or pay little attention to testing and architecture then you have a problem. With software technical debt, with your first release you won’t realize you have debt. However, a year from now when the developers have forgotten 90% of what they had worked on and you need to fix your code, you’ll make your first debt payment in the form of time, money, and opportunity lost. Over time, you can build yourself into an unmanageable code base which often requires rebuilding the application.
Under-sizing systems, building un-scalable infrastructure, not replacing systems in an orderly fashion, and not building redundant systems are just a few of the ways you can get into technical debt when it comes to hardware. This debt is often paid in downtime, lost productivity, intermittent speed slowdowns and outages, and problems with doing maintenance during regular hours. Usually people go into technical debt to avoid spending money upfront. However, study after study shows that initial hardware cost is usually a very small fraction of Total Cost of Ownership(TCO) when it comes to IT solutions.
Building Software When You Should Buy.
One of the easiest ways to build technical debt is building product you can easily acquire of the shelf. It’s often tempting to build software you think you need, but what that does is take your eye off what is really important. Sure you may be able to build a better bug tracking system than what is currently available. But you need to ask yourself, “Do I really need to?” When you build software which is not you main line of business, you end up paying for your people to solve problems which some company has already solved. Further, massive technical debt shows up later when you have heavily invested into your custom system and need to migrate to either a new platform or new product.
Not Investing in Your People
People are an often overlooked aspect of technical debt. People cause technical debt when they fail to communicate or when the company fails to train their IT people.
Further, if you have a culture which allows people to build silos around their knowledge area, you have a technical debt. If that person leaves, you will feel the pain of the debt payment, in the form of lost knowledge which requires money and time to recover (if possible at all).
Further, failing to train your IT people means you accept the status quo when it comes to improvement of your companies IT knowledge. You pay debt on failure to train when you are forced into solutions which are based on yesteryear.