Strategic Short-Cuts!

Thanks to my friend and fellow Architect, Naren for influencing me to write this blog post. I was so impressed with the concept that I felt I had to write this post.

Are you managing an IT shop that consistenly spends on Operate & Maintain Budget?
How much of your annual IT budget goes to 'sustain' your existing systems?
How much of it goes to 'extend' your existing landscape with new business capabilities?
If your spending is more inclined more towards 'sustain' mode, there are chances that you are carrying quite a lot of debts.

Yes, the subject of this blog post is about 'Technical Debts'. Here is a short article by Martin Fowler on Technical Debts. In this note, Martin defines Technical Debt as something that is accrued over quick and dirty ways of doing things.

In this note, as well as other articles that I read, Technical Debt is defined in the context of Application Development projects, where the Dev team is forced to pay the interest payments in the later phases of the release cycles. When I mention interest payments,it is the additional cost incurred in future development activities due to bad design/technical decisions that were made earlier in the cycle.

It was quite interesting to correlate this debt with Financial Debt! More than defining Technical Debts in a Project context, I was curious to understand how the idea is applicable in enterprise IT context, especially in the legacy application maintenance/support space. In typical IT spending, lions share of the budget goes for maintenance/support/operations and Technical Platform Refresh/Upgrade, etc. The question is - Does the lion's share goes to keep just the lights on? or extend those legacy apps with new capabilities?. Typically it goes for lights on operations and the organization depends largely on Heroes (be it people or IT Service Companies).If the company wants to get an insight on why the maintenance spending just stays flat on legacy apps or every single fix takes a huge amount of time, Its time to assess the Technical Debt that it carries. Once the company becomes aware of the Debt, it acquires the capability to manage it effectively.

The good thing that I liked about this idea is that it makes the bad decisions/short-cuts 'explicit' and 'quantifiable'. It is also an effective mechanism to communicate the risks to business/General management forum in non-technical language. I see a lot of relevance for this concept in the Architecture space, where I can defend the spending on Architecture/Design phase by stating the future costs on 'interest' payments.

In matured companies, you will not only report out how much of Technical Debts that you have created out of a project, You will also track and manage the Debt on a periodic basis. The companies can decide to payoff the debt once for all or pay it in increments, depending on the nature of the risk.

To thrive on this concept and make it actionable, the key pre-requisite that I see is the open culture. In a culture, where people will not get penalized for reporting the problems and there is an open atmosphere for discussing/debating the risks and mitigation options, those would be the places Technical Debts will fly.

Here is a plug-in from Codehaus for Technical Debt. The plug-in gives an indication on effort/cost required to reimburse the debt and the kind of debts detected in the code. (e.g. Code Duplication, Complexity, Violations)