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
Monday, June 07, 2004
Another hard day at work squashing bugs.
It was truly an interesting day at work today. I had not been able to reproduce one of the software bugs assigned to me and today, just two days prior to beta, the bug springs back to life!
At this stage the bug seems to be some creature, like shown in the movie Men In Black. And its back in action.
The problem used to surface only when we ran our component on ports less than 1024 on Solaris. I am sure it would have helped if I would have known the scenario earlier (any moron knows that ports less than 1k are reserved on Unix flavours). Then I found another race condition in our component. The race condition issue was another bug in incubation. I am sure it was waiting for the right time to strike. However, it was luckily discovered earlier (rather than at the customers end to make things worse).
These events resulted in the day stretching in to the night at office. But, I think I have things in control and should be able to squash the bugs out of the repository tomorrow :)
Lessons learned:
- From the port related bug, just because you could not reproduce it, does not mean it does not exist!
- From the race condition issue, you can never be too carefull while writing multi-threaded programs :)
I really appreciate the multi-threading debugging support in VC7. One can freeze/thaw/switch active threads on the click of a button. How I wish good old gdb (5.3) on Solaris would support the same...
I know its no piece of cake writing a debugger. For a wonderful explanation of what is involved read, 'Debugging Application' by John Robbins.
Good night and sweet dreams my best friend the Debugger :)
At this stage the bug seems to be some creature, like shown in the movie Men In Black. And its back in action.
The problem used to surface only when we ran our component on ports less than 1024 on Solaris. I am sure it would have helped if I would have known the scenario earlier (any moron knows that ports less than 1k are reserved on Unix flavours). Then I found another race condition in our component. The race condition issue was another bug in incubation. I am sure it was waiting for the right time to strike. However, it was luckily discovered earlier (rather than at the customers end to make things worse).
These events resulted in the day stretching in to the night at office. But, I think I have things in control and should be able to squash the bugs out of the repository tomorrow :)
Lessons learned:
- From the port related bug, just because you could not reproduce it, does not mean it does not exist!
- From the race condition issue, you can never be too carefull while writing multi-threaded programs :)
I really appreciate the multi-threading debugging support in VC7. One can freeze/thaw/switch active threads on the click of a button. How I wish good old gdb (5.3) on Solaris would support the same...
I know its no piece of cake writing a debugger. For a wonderful explanation of what is involved read, 'Debugging Application' by John Robbins.
Good night and sweet dreams my best friend the Debugger :)
Labels: programming, software engineering
