I've spent a lot of time lately thinking about Technical Debt, and how it applies to me and my organization. After I recently read "The Phoenix Project I spent even more time thinking about this.

First, what is Technical Debt? The linked Wikipedia page talks about poor decisions adding problems or debt later in code. In terms of systems and network engineering, I'd say it means shortcuts taken during the design or build or documentation process means you have an obligation to repay those debts or you will continue to pay interest on those debts continually.

What do I mean? Take a common example, building or expanding a network. The easiest thing to do is fire up the CLI and start configuring the device. Through perhaps a bit of trial and error (oops, forgot that default route or to enable ssh the first time!) you'll have a working device on the network. More than likely the other teams will be anxiously awaiting the new connectivity and as soon as the device or port is online it will go into service. All done right? Did you label the port? Did you document it? Add it to your network management system? None of those are technically required to put the port or gear into service and so they are often missed steps in organizations without strict discipline. I'd say those are clearly technical debt.

What sort of interest would you be continually paying on that technical debt? Everytime you touched that port you would spend time verifying what was connected. Next time someone needed statistics from the device you won't have them because you forgot the  monitoring. During your next outage you'll spend extra time sorting out the configuration because you are missing documentation.  Get the problem? The shortcut you took earlier has cost you, you still owe the additional debt of doing the original work, and now you have paid additionally by wasting time or maybe prolonging an outage.

What can you do? Begin making a list of your own technical debt. Maybe it is just me but I usually have a good idea of a few things I would like to have completed or done better. Once you tackle your own debt then you can get with your team, be an advocate for them and set some goals. 

Here's to a cleaner network, better documentation, fewer after-hours calls or a more stable network. And just as good, you'll sleep better knowing you finished that job right.

AuthorKelly McDowell