Defects
December 23, 2011 § Leave a comment
I often land myself on legacy projects that are in need for help. I think there is a different blog entry about this “quick fix with agile mentality”. Anyway, the thing that you can notice on these projects is that the team is spending a lot of time doing defect fixes. My first task is to do something called a heat map (thanks to @bcarlso[Brandon Carlson] for giving this name to me) to understand where the defects are coming from within the system. With this heat map in place, I begin to characterize the defects as customer request for change vs architectural issues.
The heat map tells me the portions of the system that change constantly either due to customer requests or due to architectural issues. At this point you could take these steps:
1. Every fix should require an automated test that exercise the changing code as you expect it to work
2. Use modularization, in D. L. Parnas’s sense to isolate the part of the system with most changes as shown by the heat map.
3. Once this piece of the system is properly modularized you have the ability to say: this piece is closed for change but open for extension.
What other tricks do people employ to tackle defects on an existing legacy system?
There is something called standard work, but 
Leave a Reply