There is something called standard work, but

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?

I read DL Parnas’s papers many years ago but couple of concepts stuck in my head. Two of the simplest were:
1. Modularization
2. Instead of trying to think like computers we have to learn to state difficult design decisions and hide them using modularization.

Every time i read his papers or think about them, I find a simplicity and honesty that surpasses all the b. s. and complexity that is defined as software engineering. I pay more attentions to his papers now than I had done when I was doing my Masters. It is a shame as I would have benefitted a lot if I had started focusing on them a decade ago. But I have learned since then.

Attached is one of my favorite papers On the Criteria To Be Used in Decomposing Systems into Modules

via : http://www.simplygrove.com

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules, and they have no respect for the status quo. You can quote them, disagree with them, glorify and vilify them. About the only thing you can’t do is ignore them because they change things. They push the human race forward. And while some may see them as crazy, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.

Think Different.

This website is amazing

I am totally in awe with the simplicity and beauty.

A very interesting set of videos.

I don’t agree with his assessment of kanban systems as he is using what David Anderson says. I could care less for what David Anderson thinks kanban systems is supposed to be because I think he takes a very naive picture of it. He completely ignores empowerment, stop the line culture, building quality in, which is what Taiichi Ohno says. Nonetheless the models and the videos are interesting.

Also this blog entry lists a nice group of blogs/video etc about culture and agile : http://agilitrix.com/2011/04/agile-culture-series-reading-guide/

http://video.allthingsd.com/video/d8-steve-jobs-onstage-full-length-video/70F7CC1D-FFBF-4BE0-BFF1-08C300E31E11

This is a great video talk. Talks about a bunch of stuff, but the best part is around why people stay at Apple. The best ideas have to win.