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?
December 23, 2011 § Leave a comment
I read DL Parnas’s papers many years ago but couple of concepts stuck in my head. Two of the simplest were:
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
October 26, 2011 § Leave a comment
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.
October 24, 2011 § Leave a comment
October 14, 2011 § Leave a comment
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/
October 7, 2011 § Leave a comment
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.
September 23, 2011 § 1 Comment
I think many have seen this video but in any case. This youtube.com video was written and produced by four-time space-flyer Andrew Thomas, the 10-minute satirical video was posted to YouTube – with NASA’s approval – after being screened at an agency leadership. The film follows a young engineer who attempts to present an innovative idea for a spacecraft design only to be stymied at every turn by program managers.
She finally decides to go to google and see a different side of innovation. It is an amazingly bold move on part of NASA to show the internal video.
September 23, 2011 § 3 Comments
I am always amazed by how things can be made more complex than is needed. To take an example, at the office we have doors that open only in one direction but for some reason there are handles on both sides of the door. Let me explain a bit, say you are inside a room and the door will only open if you push at it but because there is a handle i always seem to pull (My thick head can’t seem to get this straight). Now if had no door handle on the side of the door where you have to push, I would always know the direction the doors open. Not to mention, we probably would save a lot of material, probably get away with only having half of the handles. There are some doors that have locks, so maybe some simple mechanism on the side of the door where you have to push to open the lock, like a push button.
If we can do this to a simple thing like door It is no wonder sometimes we create more complexity than is needed when we do software development.