First I read Joel's Choices = Headaches. And then I read his follow-up (How many Microsofties does it take to implement the Off menu?) and of course the link to Moishe Lettvin's The Windows Shutdown CrapFest.

And I think about a project I am involved with that has as many strange interconnected pieces -- keyboards. And most especially the new "Text based TIPs" that I owe a whole bunch o posts on which are almost done.

I sang a bit about the underlying organizational complexity I am referring to in my Who runs the keyboards? post, and I can assure that the actual chain of organizational connections is even worse than the one Moishe laid out, involving the hardware team that is an entirely different division, folks in Shell, USER, Cicero, Setup, and NLS (plus the MUI dev lead who got involved due to his prior work). Things had the potential to be even worse, especially when you factor in the IME team that we also had to interact with, which means we were crossing continents, not just divisions.

We were definitely in different trees, and it could take months to see changes make it from one team's tree to all the others, especially in the earlier days of the project.

Thankfully, we took it in a different direction that stayed away from many of the problems that plagued the "Off menu"....

In our case, we provided the setup team with a library that did all the work and asked them to call it (this approach is used for all of the NLS/MUI functionality setup uses, and solves the almost-as-good old solution where the setup team would just use intl.cpl).

We still aren't meeting with the hardware folks, even though we promised to do it more often. Darn, we should work on that!

The "Cicero" (Text Services Framework) team and the USER team thankfully were put in the same org, so I could talk to someone on Hiro's team as easily as I could talk to someone one Yutaka's (like Kazuhiko), and although our source trees are in vastly different places in the hierarchy, we would regularly work with each other's private drops to verify that changes worked properly. And all of us hated process, and all of us wanted to minimize change and minimize the impact to test. So on each side me providing copies of the text file I was developing and them providing me with updated versions of TableTextService.dll, sometimes input.dll, and occasionally msctf.dll made everyone's life easier. And the same applied to the shared pieces that were used by setup that we were providing a library for that used their library as well.

We did not schedule standing meetings ever -- mainly we just sent mail when we needed something, just like they did. There was a brief panic on the setup piece of this due to a PM liaison getting kind of random and messing up what all of us thought was going on, but that PM left and everyone on both sides worked to fix up this problem.

In the end we shipped. :-)

I still owe a blog post on the story about the Amharic input method. I promise I'll try to get to it this upcoming week. It is part of a "Vista non-hero" story I have actually been working on....

So, back to the non-nightmare for a moment. How did we avoid the same kinds of problems that plagued the "Off Menu" ?

Well, I think we avoided the layer of process involving:

  • having our leads come with us to every meeting (we just told them later what was happening!);
  • having regular meetings at all when email and private builds can do the job for us;
  • involving the organizational tree that would have had to pivot on Jim Allchin (since he is the first shared management contact we all had!);
  • building up tons of process based on huge plans and goals rather than just trying to solve the problems without overthinking them;
  • having multiple points of contact from every team with every other (we tried to have one act as a liaison when possible).

Which is not to say that all of this is what happened in the "Off Menu" case, I guess I am thinking more of the problems that would have led us into similar troubles.

The moral of the story? There were teams in Vista that also worked hard to stay focused and get the job done, in addition to some reportedly pathological cases. None of the teams involved were any better or worse than any other team, and we were not alone

 

This post brought to you by ፑ (U+1351, a.k.a. ETHIOPIC SYLLABLE PU)