This great article from Forbes starts off with a good physical and personal analogy for technical debt:
Imagine you're in your early twenties and working long hours at a start-up. In order to keep up with the work load you only have fast food for lunch because it is cheap and quick. While this may allow you to meet your professional goals in the short term, over time you will realize that you are sluggish and accumulating a list of health problems.
This comparison should be obvious.
Technical debt is not something that is done maliciously but out of a perceived need - and if it's not managed properly can end with critical system failure. When you make certain shortcuts to help get through iterations quickly, there will be long term negatives associated to these short cuts.
But why can technical debt be so detrimental to your software's quality and health?
This is an important question to ask because the more you understand how to answer it yourself, the better you can explain technical debt to those stakeholders who have never dealt with it first hand.
When you have too much technical debt, it makes processes highly inefficient - to the point where in some instances innovation will come to a full stop.
For example, Twitter first built its platform front end with Ruby on Rails - however, later on when they were seeking to add new features and functionality they were unable to do this quickly and efficiently. Twitter had to eventually switch to a Java server in order to pay back their technical debt and add new features on demand.
To many, technical debt may still seem like an abstract concept but it does accumulate real costs: CAST estimates that the average cost per line of code of technical debt is $3.61, and for Java $5.42. But the costs of tech debt also accumulate in terms of how it effects developers themselves. Developers increasingly become more frustrated and demoralized as technical debt mounts and makes their jobs more difficult.
So once you know all this about technical debt how do you deal with it?
Make sure you know how much and where there is technical debt in your systems, because if you don't know this there is no possible way you will be able to pay it back. Once you have a log of your tech debt make sure you make a plan for weekly payments to incrementally improve your debt standing while still being able to work on new projects.
However, it is important that once you realize technical debt is extremely detrimental to your success, that you set in place a culture of development that doesn't force people to take shortcuts which result in debt. Make sure that when you are starting a project to take into consideration how it will grow in the future so that you code accordingly, and won't have issues adding on new functionality down the line.
Technical debt is very real threat to your system performance and therefore has to be dealt with accordingly.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.