Tech-sand vs. Technical Debt

In a recent conversation I was asked to explain the difference between what I call Tech-sand and what Ward Cunningham called Technical Debt. First, I do not see them as the same thing. In fact I see technical debt leading to tech-sand. The more technical or design debt that a business incurs, the harder it can be to get out of debt and move forward. The business is then stuck in tech-sand, not able to move forward, and not able to easily move back and undo what got them there in the first place. And don't even get me started on the irrelevance of considering sunk costs.

Yes some organizations plan for technical debt. In fact, I would argue that most organizations realistically have to absorb some amount of technical debt to remain proactive and competitive. Let's face it, IT is a commodity that is only differentiated by how well it is aligned with business and how well it is used to build barriers to erosion of competitive advantage. The idea behind knowingly incurring technical debt is to pay it down by incrementally replacing components or systems before "interest" payments (in the form of increased maintenance costs) become too large a part of yearly budgets or before aging systems are no longer nimble. Steve McConnell explains it well in his take on technical debt. I see it simply as how leveraged your organization is with technical debt. The more technical gearing you have the less efficient you are.

I argue that my term, Tech-sand, is broader in scope than software and hardware design and development. It is actually a worse case result. It can be the result of many different architecture and design decisions that are not well thought out, or based on politics or flawed financial models that do not understand the TEI (Total Economic Impact). Not understanding the true TCO of a solution can also lead to technical debt and and complete misunderstanding of what it means to service the technical debt.

Tech-sand can also be compared to a big ball of mud. However, again, it is not limited to strictly design and development of software or hardware.

The concepts of technical debt, servicing technical debt , and TEI should be looked at with the same rigor and systematic approaches that we use to judge the financial worthiness of companies. Apply the ratios. Today's IT budgets primarily go to operating expenses, easily 60% - 70% in some cases. How much technical debt does a company have and how much of their budget is used for operating?

How well a company manages IT and how well they make important technical and architecture decisions affect these operating budgets. Simply put, the more technical debt IT incurs, the more money in the operating budget it will need to service said debt. The trick here is to quantify this debt and monetize the budgetary aspects of its effects. Adding more people to the budgeted workforce to service a poorly designed or out of date system surely adds to the operating costs and can be seen as resulting from technical debt. Spending more every year, after factoring out customary software and hardware annual increases, points to a disturbing and identifiable trend. The IT department and more importantly the business is incurring technical debt faster than it can pay down the principle of said debt by replacing aging, poorly performing, and/or poorly designed systems.

Sooner or later these poorly performing, and myopic organizations will find themselves in Tech-sand. At that point, incremental steps are no longer adequate and major initiatives are needed.