This post is part of 101 ideas for agile teams.
Your team struggles with its code. The code is often too difficult to understand. Defects sneaked in because changes had some not anticipated side effects.
New team members have a difficult time understanding what the code does, why and how.
Whenever a team member does not understand how a piece of code works, what it is for or what depends on it, the team picks another team member who tries to explain.
When the “expert” can’t explain the why, what and how in a time-box of ten minutes, the team is obligated to refactor the code in a way that it can be explained in ten minutes.
If you can’t explain it in ten minutes, refactor it to something simpler, so you can.
What you gain
The refactoring will lead to code that is much easier to understand and therefore there will be less defects, features will be implemented faster, and team members will be happier and more courageous to take on difficult tasks.
Your team members will improve their presentation and visualization skills.
Your team members will learn to better communicate with each other on a technical level.
Even if your team can explain the topic in ten minutes, you have renewed the knowledge in the whole team about this topic.
You notice when your knowledge about the code has aged and is not correct anymore.
Your team members get more courage to make changes in the whole code base because knowledge is shared. This allows true collective code ownership.
How to strengthen
Once a week, choose some random piece of code and see whether the team can explain it to themselves within ten minutes. Otherwise, start refactoring!
In an ugly, difficult code base, this will result in too much need for refactoring. Limit the amount of time spent on refactoring, or no new features will find the way into the software. But start refactoring, otherwise the mess will become even worse!
Thanks to Adrian Krummenacher for sharing this idea with me.
Please help me improve this idea by providing feedback.