Its Purpose?
To help people understand what parts of the system have excessive code-smells and need either refactoring or redesign.
How did we execute it?
- Maintain a list of the technical debt – We have a list of all the technical debt in the system on our wiki. As a team, we identify parts of the system we want to address as a whole and discussed different strategies for implementing it. Some of the debt stays on there until we all agree on a common approach, although we try to remove as much of it as we can, especially if they are small things
- Walkthrough the list with new people – We sat down and expressed our concerns by walking through the list and explaining perhaps how it came about and what effects each item on the list have.
Photo taken from Jekemp’s photostream on Flickr under the Creative Commons license
Why Is It Important?
All big projects have some part of the system that doesn’t seem particularly right. Given commercial time constraints, you never have the time to address all the issues to make every single bit of the code perfect. It’s better to keep people aware of these compromises so you address them when you have time.
From experience, I’ve also found it’s very easy for new people to projects to criticise parts of the code that obviously aren’t ideal. It’s a very healthy process having new eyes on the material to bring a different point of view and offer different approaches, although there are better ways they can express their concern without making incumbent developers feel criticised.
Providing the opportunity to openly discuss all areas of the system the team would like to collectively improve each of them has been an effective way at meeting all of these goals.
