Saturday, February 18, 2006
Interesting talk by Charles Petzold - Does Visual Studio Rot the Mind?
Does Visual Studio Rot the Mind?
Ruminations on the Psychology and Aesthetics of Coding - By Charles Petzold.
Ruminations on the Psychology and Aesthetics of Coding - By Charles Petzold.
Labels: software engineering
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
Windows Workflow Foundation Framework
Yesterday I was playing the recordings for VSLive held at San Francisco and there was a session by Paul Andrew (Technical Product Manager) on Windows Workflow Foundation.
Windows Workflow Foundation is an extensible programming model and runtime components for building solutions on the Windows platform. It supports human and system workflows. The interesting aspect is integration provided with Visual Studio (graphical means to define workflows) and the ability to embed the workflow runtime engine (provided as a library) in any windows application (be it console based, Win32 etc.).
Window Workflow Foundation looks very promising and is something to watch out for. I think addressing the workflow problems at the OS level is new and opens amazing opportunities for various vendors. I am yet to get my hands dirty with Windows WF. Hope to find some time soon.
Following are some useful links:
Windows Workflow Foundation - The Official Microsoft Windows Workflow Site
Introducing Microsoft Windows Workflow Foundation: An Early Look - David Chappell
Windows Vista Developer Center - Windows Workflow Foundation
Presentation by Paul Andrew (VSLive at SFO)
The activities provided by Windows Workflow Foundation core library have a striking resemblance with "activities" in the BPEL runtime language. Here is an interesting article by David Chappell on "The case against BPEL - Why BPEL is less important than you think".
Windows Workflow Foundation is an extensible programming model and runtime components for building solutions on the Windows platform. It supports human and system workflows. The interesting aspect is integration provided with Visual Studio (graphical means to define workflows) and the ability to embed the workflow runtime engine (provided as a library) in any windows application (be it console based, Win32 etc.).
Window Workflow Foundation looks very promising and is something to watch out for. I think addressing the workflow problems at the OS level is new and opens amazing opportunities for various vendors. I am yet to get my hands dirty with Windows WF. Hope to find some time soon.
Following are some useful links:
Windows Workflow Foundation - The Official Microsoft Windows Workflow Site
Introducing Microsoft Windows Workflow Foundation: An Early Look - David Chappell
Windows Vista Developer Center - Windows Workflow Foundation
Presentation by Paul Andrew (VSLive at SFO)
The activities provided by Windows Workflow Foundation core library have a striking resemblance with "activities" in the BPEL runtime language. Here is an interesting article by David Chappell on "The case against BPEL - Why BPEL is less important than you think".
