Saturday, February 11, 2006
Software engineering lessons learnt - Microsoft Whidbey release.
Interesting (recorded) session on How Microsoft Does Software Engineering Or, "How We Make the Sausage: Lessons From the Factory Floor." by Russ Ryan. Russ is serving as Product Unit Manager (PUM) at Developer Division Customer Product Life-cycle Experience Team.
Russ talks about experiences and lesson learnt during the Whidbey release. He explains that milestone planning is critical and how milestone cycles should not be too small or long....they need to be just right. At MS milestones are around 8-9 weeks. MQ is the quality milestone where you "get clean and stay clean" by clearing your bug debt accumulated over previous milestones. He mentions that "moving bugs forward is not a good idea - carrying the bug debt is expensive".
Some interesting things covered are:
- Dog food - Ask teams to consume software developed by other team prior to release itself. For example the tools development team will ask other team to use newer tools prior to release.
- Build process - There is a separate build team (24 hours) and concept of a "Build Facilitation Developer" (BFD). A BFD is a team member who is on call to provide HOT fixes for any build breaks.
- Large projects "coast in" as opposed to ending suddenly.
- Concept of "end game" mode. War teams are comprised of team members with prior ship experience.
- "Tell mode" and "Ask mode". In "Tell mode" checkins are communicated to the war teams. In "Ask mode" checkins have to be approved by the war teams.
Finally the most important things I think Russ mentioned:
"Once you checkin the code, you are hostage to the code"
You can find the blog here: DDCPX Team Blog
Russ talks about experiences and lesson learnt during the Whidbey release. He explains that milestone planning is critical and how milestone cycles should not be too small or long....they need to be just right. At MS milestones are around 8-9 weeks. MQ is the quality milestone where you "get clean and stay clean" by clearing your bug debt accumulated over previous milestones. He mentions that "moving bugs forward is not a good idea - carrying the bug debt is expensive".
Some interesting things covered are:
- Dog food - Ask teams to consume software developed by other team prior to release itself. For example the tools development team will ask other team to use newer tools prior to release.
- Build process - There is a separate build team (24 hours) and concept of a "Build Facilitation Developer" (BFD). A BFD is a team member who is on call to provide HOT fixes for any build breaks.
- Large projects "coast in" as opposed to ending suddenly.
- Concept of "end game" mode. War teams are comprised of team members with prior ship experience.
- "Tell mode" and "Ask mode". In "Tell mode" checkins are communicated to the war teams. In "Ask mode" checkins have to be approved by the war teams.
Finally the most important things I think Russ mentioned:
"Once you checkin the code, you are hostage to the code"
You can find the blog here: DDCPX Team Blog
Labels: management, software engineering
# posted by Paresh Borkar @ 10:06 PM 
