Preview Mode Links will not work in preview mode

Agile Coaches' Corner shares practical concepts in an approachable way. It is for agile practitioners and business leaders seeking expert advice on improving the way they work to achieve their desired outcomes. If you have a topic you'd like discussed, email it to podcast@agilethought.com, or tweet it with #agilethoughtpodcast.

Jul 1, 2022

This week, Dan Neumann is joined by Agile’s Thought Chief Architect, Michael Cooper to explore the topic of Technical Debt.

 

In this episode, Dan and Mike share how Technical Debt has become a dirty term among technical and non-technical people, where it can be considered to be a waste of time and money. Mike is here to demystify Tech Debt and talk about the necessary steps to take when encountering it, like finding its root cause and advancing a strategy to address it.

 

Key Takeaways

  • What can be some indications that technical debt is present?

    • The first sign is that things are not going right, people can be unhappy about some aspect of the platform, system, or project.

    • One indicator is that the velocity is slowing down.

    • When decisions are procrastinated we accumulate tech debt... is this a deliberate choice? Not really, but we still refuse to make decisions to address it.

    • Stress is an indicator of Tech Debt.

    • The passage of time will create Tech Debt.

    • When defect rates get to a point that they are no longer tolerable or acceptable, you have to consider the decisions that were put off in order to reach that state.

  • How to avoid technical debt:

    • Automated Testing

    • Unit Tests for capturing the developer’s intent

    • Static Code Analysis tools (such as SonarQube) for generating metrics about code complexity.

  • Most code in the world has high-tech debt. However, it is not an issue because people don’t need to change it.

    • Software becomes “hard” when it gets enough tech debt.

    • The most used strategy is to do nothing when encountering tech debt, and if you are not making changes to the code, it is an acceptable and reasonable approach.

    • The highest reach approach is trying to change and rewrite the entire codebase. You are likely to lose the functionality that you originally had.

    • One way of approaching tech debt is to make slow changes only when you hit that piece of code again.

  •  

  • Mentioned in this Episode:

  • What is technical debt? By Chris Cairns and Sarah Allen

  • Applied Software Measurement: Assuring Productivity and Quality, by Capers Jones.

  • Agile Estimating and Planning, by Mike Cohn

  •  

  • Want to Learn More or Get in Touch?

  • Visit the website and catch up with all the episodes on AgileThought.com!

  • Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!