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.
Lack 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
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.
Lack 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.
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.
1Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004, pg. xvi