It’s a given. Technical Debt kills a Team’s code. So, what can the Team do about it? How can the Team prevent the development of Technical Debt from creeping into its code? Here’s 5 Ways to get your Team on the right track to preventing Technical Debt.
1. Keep Your Eyes On The Prize
Reviews are the best way to keep quality up, so have lots of them: architecture reviews, test reviews, design reviews, code reviews, and so on. Remember that Stories are promises for conversations. A good ScrumMaster will constantly push the Team to have these conversations, to go beyond Pair Programming, to make sure the appropriate SMEs are involved, to engage in frequent reviews to increase quality and knowledge.
2. Test Coverage
Putting many eyes on the code creates a better product and smarter people, but it doesn’t solve the problem about what to do for the future. What does the Team do to protect the code from future developers? The best way to make the code easier to use for future maintainers and extenders is to have extensive automated test coverage. This gives future developers a better understanding of the code and less fear of changing it, and the code itself will not fear the developers.
There are two types of tests the Team should perform:
- Black Box Tests
Black Box tests illustrate the externally visible behavior of the system and provide the best documentation. They can be thought of as executable requirements, representing a highly-detailed statement of what the system actually does.
- Unit Tests
Unit Tests reflect the design of the system. They illustrate what each of the components actually does and how they all fit together. One of the best development paradigms, Test Driven Development (TDD), focuses on testability as the primary motivator for component design. The TDD paradigm not only provides code that is protected by unit tests, but also provides components that are highly cohesive and whose coupling is well understood.
3. Continuously Cleanup
In order to produce and maintain Clean Code, it is necessary to do continuous cleanup, known as Refactoring. The key word here is ‘continuous’ – not ‘every once in a while.’ Experience shows that once the amount of dirty code gets too big, it is very hard to clean it all up. Test Driven Development, Coverage Testing and Refactoring are intricately linked. The ability to do all three is considered to be a core competency of an Agile Developer.
4. Embed Current Technical Documentation
To change code easily, developers need to understand what they are actually looking at so they can find what needs to be changed. The code itself can’t tell you what design decisions were made and why they were made. It can’t tell you what the logical groupings of entities into modules are. It is often hard to discern the intent of some complicated snippets of code. That’s why the code often requires technical documentation. At the very least, there should be comments embedded in the code to help developers understand what is going on. It’s important that this embedded documentation be kept current. As the code changes, the technical documentation will require its own refactoring. Having no documentation is bad, but having incorrect documentation can be worse.
5. Adopt XP Practices
XP (Extreme Programming) contains a set of development practices that produce Clean Code in an object-oriented environment. XP practices are well-defined and many coaches exist. It is quite common for successful Scrum Teams to use XP practices when working on Stories that produce code. Like so much in Scrum, XP practices are simple. But not easy.
Looking for more help preventing Technical Debt? We’ve got training for that.
As Always, Stay Agile.