A separate milestone for quality? I thought we built quality into the product in all milestones...

For the uninitiated, MQ or Milestone Quality is the newest experiment at Dev Tools. This is a milestone that happens right before the beginning of a new product cycle (which usually starts with M0). This period is supposed to be used to build the right engineering processes, infrastructure and tools around the product. I must confess I don't like the title MQ much, albeit I agree that other options like M(-1) or M(EE) would sound equally absurd. Being a tester, I can go on about how building quality is an ongoing process and not limited to a milestone, yada yada. But, looking beyond the name, we are planning some seriously cool stuff in MQ at Dev Tools.

When I heard about MQ, I was "super excited"! (does that sound familiar? ;-) I am a big fan of engineering excellence(EE) and never spare a chance to dabble with anything new that I sense may be useful to our team. Before the process haters inc. start thulping me, believe me when I say there is much more to EE than ponderous processes and tedious tools thrust down your throat by the diabolical management. The milestone sounds like a time to look at past mistakes, take corrective and improvising actions, write tools, apply relevant processes and basically fix systems that are impeding your efficiency as a team. That means we start Orcas with a clean slate. Sweet!

There are division wide initiatives like hitting a certain threshold percentage of code coverage for all assemblies, eliminating product bug debt, eliminating test bug debt, feature crews, implementing improved code review systems, writing uniform test frameworks, merging the dev and test code into a single depot, adding features to test harnesses and writing some useful tools to replace or enhance functionality of existing systems. I admit the scenario sounds a bit bleak for the devs; appearing like an extended season of bug fixing, but hey, I never said being a dev was fun ;-) On a serious note, MQ will be a great time for some critical introspection and implementing all those creative ideas and tools that you knew would improve your efficiency, but you just did not have the time to do while shipping. The division wide initiatives have some very innovative tools and mechanisms that I can't wait to try. And there are a bunch of items that are feature group specific that also need to be implemented. I am looking forward to MQ right after we ship. More on specific stuff that interests me in further posts.

Like Amnon Horowitz says "MQ is not a time to do post mortem, but a time to take corrective action after the postmortem has already been done."

Comments

• Anonymous
  July 17, 2007
  A couple of weeks ago, Grady Booch gave a lecture at Microsoft. It was a pleasure to hear of my software
• Anonymous
  July 17, 2007
  A couple of weeks ago, Grady Booch gave a lecture at Microsoft. It was a pleasure to hear of my software