Moral hazard is a situation when a party is more likely to take a risk because they are not the ones bearing the possible costs of that risk. This post concludes that one of the sources that can contribute to technical debt is moral hazard – which comes from the person coding being motivated to get the code done quickly and not being cautious of cutting corners because of their lack of commitment to the possible costs. This connects to another interesting point that this post makes; code deficiencies do not become technical debt until there is a commitment to address the deficiencies. Basically, it’s not a debt if you don’t have to pay it off – but creating these deficiencies raises the probability of having to commit to fix the code. This probability of the costs that might be taken on is what this post calls technical liability. The liability must be understood in order to decide to invest in reducing the deficiencies created by technical debt.
This post is an interesting addition to the differing perspectives surrounding technical debt and has some new insights surrounding culture of creating technical debt. To read the full post go to: http://murraycantor.com/2014/07/30/technical-debt-technical-liability-and-moral-hazard/
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.