As developers, after working on the same project for a while, we start to remember sections of our code base which aren’t quite ‘up-to-par’ with either team or industry standards. We begin dreading working in those areas of the project and sometimes even avoid stories or tasks involving these problem areas. Our first instincts should be to refactor the area or clean it up in some way so that these smells do not haunt the next person who must work in that area of the system. Unfortunately, it is not always as simple as just fixing the issue immediately and soon a small task can become bloated when we head down those rabbit-holes of maintenance.
Our initial solution to this problem was to simply document these code smells on a white board beside our scrum board under a section called ‘Code Smells’. Each smell was represented by a card which could then be prioritized based on the impact it was causing. This was great because all of these problems in the back of everyone’s mind were now right there in our faces and even the business could see them. It was now more apparent what might cause you issues when you worked on a given story. These code smells were still addressed as part of stories if it made sense to fix them immediately but we could also do some work or investigation on the smells during short periods of spare time, often before lunch or at the end of the day.
This method did work for quite some time; however it was soon apparent that it was not just bad code which was slowing us down. Other issues arose such as deployment complexity, test runtimes, etc. which did not seem appropriate to classify as code smells even though they were undoubtedly hurting our team’s velocity. We came up with the idea of renaming our Code Smells section to ‘Speed Bumps’. This new name gave us a place to track anything and everything which was slowing us down. They are still addressed in the same fashion, either as part of a story or during spare time. The benefit of the rename simply gave the team more certainty when adding issues to the list since if there was something limiting their productivity; they were encouraged to either deal with it immediately or add it to the list. This makes any technical debt in the project more manageable because everyone becomes aware of them and they can be prioritized once recognized.
I am curious if any other development teams out there utilize a similar or even completely different strategy for addressing technical debt. What works for you?
By: Jesse Webb