Technical Debt is Risk Management

by

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/

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|