The concept of Technical Debt has been around for decades. Originating in the software development area, Technical Debt describes the accumulation of “we should probably fix that” places in the code. However, Technical Debt does not just apply to software, it applies to the entire IT world. Hardware, software, infrastructure, security, and applications all have their technical debt.

Technical Debt is a little like Schrodinger’s Cat, as it may or may not be there. Some technical debt is never a problem. Some of it blows up spectacularly. Some assumptions we make are fine. Others aren’t.

Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.

Here are some well-known examples:

• In the 1970s, everyone knew they would replace their software by the year 2000, so two digits for the year were fine. Until it wasn’t.
• A developer makes an undocumented assumption about the underlying operating system that eventually becomes false.
• The database developer writes code that only works with on-premise databases because there are no plans to move this critical database to the cloud. Until there are.

Technical Debt can’t be completely eliminated, but there are things we can do to help.

1. We’ll finish that later. Chances are you won’t. The cleanup tasks that are typically needed at the end of a project are never as shiny as the next new project. So these tasks don’t get done. The old server isn’t shut down. Security settings are cleaned up from the rollout. Focus & Finish to make sure we complete these tasks.
2. Let’s see if this works. Troubleshooting often has several try/fail cycles before we find a solution. How often does the “try” get completely unwound? Change a setting. Did you change it back? Try a different connection. Did you change it back? Install a patch. Should the patch be removed? Should it be installed for everyone in case they have the problem? Unwind your “tries” to reduce the little land mines you leave for yourself.
3. Just patch it again. Imagine a machine that, for years, gets fixed by bailing wire and twine. At some point, the fixes will overwhelm the proper functioning of the machine. When a problem occurs, do we take the time to make a more permanent fix or do we just add some more twine and keep going?

The two reasons most often given for accepting some level of Technical Debt are, unfortunately, the two most valid: time and money. The standard joke is “We don’t have time to fix it today but we will make time to fix it tomorrow.” The unfortunate reality is this will be true for any organization at some level.

The fight against Technical Debt is constant. We will make tradeoffs and accept risks daily. Some will turn out wrong and others will be right. Paying attention to the concept of Technical Debt can make your future a little less painful.