Technically speaking (pun intended), we can define Technical Debt as deficiencies in the code, technical documentation, development environments, 3rd-party tools and development practices, which makes the code hard for the Team to change. The reality is, Technical Debt is everything that makes your code hard to work with. It’s an invisible killer of software, and must be aggressively managed.

To help Scrum Teams everywhere get a better handle on Technical Debt, we’ve identified the four most common types.

  1. Lack-of-TestsLack of Tests

Code that is not protected by tests is very hard to change. Developers have little or no confidence that they have successfully made a change unless they have tests proving that they didn’t break something. This lack of tests is such a big deal that Michael Feathers defined legacy code by the statement “legacy code is simply code without tests.”1

  1.  Bad-DesignBad Design

When we say bad design, we really mean code that is poorly structured in some way. There are three structural issues that we focus on:

  • Once and Only Once Rule
    The same behavior is not duplicated many times throughout the code base.
  • Highly Modular
    Each of the modules must be highly cohesive and loosely coupled to each other.
  • Intention Revealing
    Each of the modules should have an intention-revealing name, allowing developers to quickly grasp what the module does and why it is there.

  1. Lack-of-Technical-DocumentationLack of Technical Documentation

In order to change code, a developer needs to be able to find the code that needs to be changed. Documentation doesn’t need to be exhaustive; it could be imbedded in the code or in a Wiki. Some sort of technical documentation is needed to make the code understandable.

  1. Poor-ReadabilityPoor Readability

A lot of the code currently being written will be around for 5, 10, or 20 years and it will be continuously maintained and changed throughout that time. The sheer size of the code, as it grows, will make its maintenance harder and harder as time goes by. Making the code readable means it’s easier to modify or change. Here are some suggestions to improve readability:

  • Another Set of Eyes
    Team Members have other developers read the code it to make sure that somebody else understands it.
  • Break It
    Break the code into virtual modules by using comments explaining what the developer’s intent is for the next piece of code.
  • Be Common
    Use common, well-known, coding practices to make future developers comfortable with reading the code.
  • No Secrets
    Use intention-revealing names for the variables, methods, and classes to self-document.

Having high amounts of Technical Debt is probably the number one impediment to Teams agility. Understanding the root cause of your Team’s Technical Debt is the first step towards effectively managing it.

Looking for more tools to help your Team with Technical Debt?
We’ve got training for that.

As Always, Stay Agile.

Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004, pg. xvi

Leave a Reply

Your email address will not be published. Required fields are marked *