There is always a battle between the amount of time you have to get things done and the amount of work you have to do to get those things done. There is usually less time than what you need to complete all that work. This time vs. work dynamic is what creates technical debt. Hitting a release deadline is often valued over writing clean code, which leads to technical debt build up. This means the next release you are working on is going to take longer, leading you to take on more debt. A cycle like this is dangerous because it leads to poorly constructed code and can even result in system failures. You need to understand technical debt in order to avoid this.
These are the question on technical debt that need to be answered before you can begin to manage it:
- What is exactly technical debt (and what isn’t it)?
- Where does technical debt come from?
- When is technical debt okay?
- What issues does technical debt cause?
- How can you measure technical debt?
- How can you reduce it?
- How can you avoid incurring it?
Tech debt is all the internal things that you have chosen not to within a specific release, but will have to address later impeding the speed of your next release. It means quick and dirty development. Technical debt is more than just a mess; messy code has not positives to it, whereas technical debt can have business advantages (being first to market). Taking on technical debt has to do with project constraints.
So what are some examples of technical debt?
The typical example would the huge source file in the code base that every developer fears touching. This module needs to be broken down into manageable pieces, but developers know that doing this could slow upcoming releases by weeks. However, adding onto the module without refactoring just adds onto the present technical debt. So the longer refactoring is put off, the higher interest paid on the debt becomes (interest in this case is added complexity of every change you’ve made on the code). There are other ways technical debt can manifest its costs, from an operational perspective large amounts of technical debt make the risk of downtime extremely high.
If this is technical debt, than what isn’t?
Ultimately sloppy code, dirty hacks, and unreadable code are not technical debt. Technical debt implies there was a decision taken to incur it, poor skills as a developer do not qualify as a cause of technical debt.
It is necessary to know how to exactly define technical debt because without a clear understanding of what it is and what it is not, managing it is almost impossible.
To read the original post, visit here.
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.