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?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Defects at There is something called standard work, but.

meta

%d bloggers like this: