Technical Debt
Technical Debt
What is it and how do we deal with it in Technology.
Firstly, technical debt can be compared to financial debt in that longer you take to ‘pay’, the more interest will be incurred.
Technical Debt also includes design or code debt.
In simple words, technical debt is build up when you do not keep a code or design updated to the latest technology or design and functionality concepts.
Lets take a few examples to understand.
· Enterprise Resource Planning (ERP) systems generally have a 2-4 major software releases per year. The releases include, code fixes and new functionality. Let’s assume you do not upgrade for two years. The technical debt are the issues you are facing because you have not applied code fixes and the missed opportunity of not using new functionality.
· A system has been build using Microsoft .Net technology and Microsoft SQL server. The system was build 4 years ago and has been running without any issues. The newest version of .Net and SQL Server and 3 version higher. The technical debt is 3 versions but in this instance you have consciously decided it okay and accept the debt.
· The IT strategy is to use the latest Browser. Taking the same example .Net system, the technical debt must be remedied in order to me the IT strategy. In this instance, you are paying the debt.
Remember, technical debt is like financial debt. Interest accumulates interest. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. Required changes that are not completed are considered debt that must be paid at some point in the future.
What's the easiest to measure all your technical debt. Firstly, you need to define your architecture standards e.g We will always have software version N-1 where N is Version or Software standard .Net 4.0
The next step is to map your entire software estate to the standards and see where you are. Another method could be to Map you estate once you have this data to TIME model.
- Tolerate
- Invest
- Migrate
- Eliminate.
Using these categories and mapping your estate will provide you the data to build your debt strategy. Add a timeline to determine you overall plan.
So in summary – companies need to consider technical debt as the longer systems are left, the more debt is accumulated.
A good read! From my biased mainframe side, you have to keep adapting or you will accumulate technical debt (what I sometimes call "a piano on your back") and die.?? This means inter alia using latest B-tree algorithms, 24/7/365 monitoring of record limits and system resources, automated management reporting, 100% automated testing at volume, having the best software development tools etc.etc But there's something else. It's PEOPLE.?? For me, this means keeping staff to a minimum but retaining the very best staff with very big packages.? All staff should be technical.? This is IT.? This is technology and technology is deeply technical.? No room or money for non-programmers or non-user experts.? You wouldn't get on an A380 if your "Captain" said "Well, I've done this on Flight Simulator, it's quite easy really" In my experience, the best IT leaders have been the ones who have used the system in the real world or have programmed and designed the system functionality.