Mind your (Technical) Debt

Post date: Jul 04, 2017 6:22:52 PM

“Some debts are fun when you are acquiring them, but none are fun when you set about retiring them.” – Ogden Nash

Technical Debt is one of my favorite terms in IT. Techopedia credits the term to Ward Cunningham and was originally intended to equate software development choices to financial debt.

“Imagine that you have a project that has two potential options. One is quick and easy but will require modification in the future. The other has a better design, but will take more time to implement. In development, releasing code as a quick and easy approach is like incurring debt - it comes with the obligation of interest, which, for technical debt, comes in the form of extra work in the future. Taking the time to refactor is equivalent to paying down principal. While this takes time in the short run, it also decreases future interest payments.”

For me, the term Technical Debt is useful more broadly - across all of information technology. I believe the term succinctly describes the sum total of an organization’s decisions, good and bad, over a period of time. As the debt from your choices accumulates the compounding interest can become a drag on the ability of IT to serve the business efficiently. This often manifests itself in costs well above industry standards and a decreasing ability to serve the business’s needs in a timely manner.

I mentioned good and bad decisions because often, well intentioned, sound business and technical decisions can still result in Technical Debt. We live in very dynamic times and no technology or business decision is immune to the changing landscape. As the business context changes and technology advances, its possible, if not likely that a decision that was good at the time, is no longer the best fit for the organization. Think of this like entropy – a gradual decline into disorder.

Talking about an organization’s Technical Debt should not be taken as an insult to those responsible for the previous decisions. I like to give people the benefit of the doubt and I assume that people generally want to do a good job. None of us are immune to bad decisions or good decisions turning bad as situations change. Often the best we can hope for is to make the right decision given the known options under the constraints we have. Constraints can be: lack of time, access to viable options, changes in business strategy, incomplete or inaccurate understanding of the root problem, limited funds, limited resources for implementation or support, lack of expertise, the list goes on and on. We all aim to make the best decision we can with the information we have at the time. No decision is permanently immune to becoming debt, entropy is a natural outcome and blame is not helpful.

Lets talk more specifically about what Technical Debt looks like in the modern enterprise IT organization. Servers, storage, networking gear etc all have a reasonable service life. Reasonable means different things to different people; from an accounting point of view its common to depreciate assets over a 3 to 5 year period. From a support perspective, manufacturers typically support hardware for around 5 years. As you go beyond 5 years it can be difficult and increasingly expensive to get replacement parts or buy extended warranties. On the software side, devices running software more than 5 years old often are not fully maintained by the manufacturer and no longer receive security patches and software updates. These are generalities but I believe them to be directionally accurate.

As an IT department budgets for hardware replacement cycles it can be tempting to let devices go beyond their projected life and extend out beyond that 3 to 5 year window. If it ain’t broke, don’t fix it! Viewed through the lens of Technical Debt the organization must realize that this decision has consequences – good and bad. In the short term this decision has a positive effect on the balance sheet or allows for reallocation of budget to more pressing priorities. In the long term you are taking on Technical Debt and the interest it carries. The enterprise takes on risk in many forms, most of which may not be completely evident to the decision makers. This risk includes: security risk (lack of patches etc), retention risk (quality resource don’t want to work on old stuff), performance degradation, higher likelihood of an unplanned outages, diminishing expertise on aging systems, the list goes on and on. As I mentioned above, as your Technical Debt stacks up you will inevitably feel its compounding effects as a drag on your productivity.

From an IT strategy perspective, it is essential to make sure Technical Debt is a familiar part of Senior Leadership conversation. Technical Debt as a high-level concept is useful in encapsulating the risks described above. While Technical Debt cannot be avoided completely there are several strategies for minimizing the amount of debt you take on and mitigating the interest. In a perfect world it would be great to place a quantitative dollar value on the organizations Technical Debt. I look forward to exploring these topics on a future blog post. Please stay tuned and as always – please provide feedback or ask questions.

Illustrations borrowed from:

https://www.activestate.com/blog/2016/06/technical-debt-high-tech-ceos-perspective

https://www.linkedin.com/pulse/technical-debt-infinite-mortgage-your-system-julien-dollon