If refactoring code reduces a code base by 80%, then the chance of missing a necessary change in the code base and the risk of missing something in testing that damages the production business are also reduced. Therefore, by this logic, the management of technical debt is in fact risk management. Using the analogy of a kitchen for technical debt can be helpful – a kitchen where everything is in the place a professional chef would expect it to be is a clean kitchen. However, a kitchen where things are in the wrong place and scattered around is kitchen with technical debt because the chef has to clean up and prepare before even beginning his work.
Every development team will have their own definition of where things should be in their code – anything that does not conform to this standard becomes technical debt in the code base and makes working with this code significantly more risky. The types of risks that can be introduced by the presence of technical debt are:
- Delivery Risk – Technical debt has a habit of blowing up in the test phase were it can no longer be managed by responded to. For example, a bug can resurface several times because of a lack of proper regression testing.
- Business Care Risk – if code contains tech debt, there is a higher probability that the code will behave in more unpredictable ways than if it were without debt. This means that changes made to code may not present the value expected.
- Risk to Existing Model – when code has technical debt the likelihood of it causing a failure in production that damages the existing production system increases greatly.
If a team is approaching a project from a risk management perspective, paying off technical debt before making any changes is the more responsible move. By looking at the code base as a portfolio of sold call options makes it so every component of the system has its technical debt accounted for. The measure of technical debt present should be calculated as how much effort it takes to pay it down, how complex the debt is, and how many team members can work on the component. The product owner can create what is called a “tornado map” which is a high level road map for the next 6 months to a year by which the team can decide what debt to address now and which can be left for a later date. In some cases technical debt may take a long time to fix or be too complex to estimate effectively, paying down this debt early is often the best solution.
Technical debt has quite a bit to do with the skills and perceptions of the team working on any code base. One team may consider their code base clean when in reality it contains a lot of risk. This is an instance when someone with a lot of experience in identifying dead code would be helpful.
To read the full post go to: http://theitriskmanager.wordpress.com/2014/12/31/technical-debt-is-risk-management/
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.