Frustration with Process, Progress, and Context Switch Costs.

Okay, lunch is done so now I'm going to write my second post of the day before going out to play some flag football. Random note, writing two blog entries in one day feels odd to me. I don't know why it seems like I should only have one post per day but it feels far more natural. Anyway, this blog entry requires a lot of setup and is likely to ramble around a bit so so let's just get started.

I stopped blogging for the last three weeks, right in the middle of PDC05, for two reasons. First, I was tired. PDC05 was invigorating and fascinating but the hour after hour of conversations were mentally and physically (I lost my voice and caught the "convention cold") draining. Second, I was frustrated and that frustration prevented me from truly recovering for a couple weeks.

The frustration also drenched my writing in sarcasm. I learned the hard way in my first few years at Microsoft that writing when frustrated was extremely good way to upset people who don't know you well and sometimes even upset those that do know you well. So, I held off... until today.

First, let me present a fact about me that I probably should have posted a long time ago:

I am fiercely customer focused. That said there is a hierarchy in the people that I consider customers. First and foremost in my mind is the end user of software (I'm a software developer, so I'm only focused on their software needs right now). These are the people that use software in whatever way that they do to do what ever they do. These people may or may not be computer experts and every attempt should be made to make their lives easier. Second in the hierarchy are the developers building software for the end user. I am a "platform guy". I like to think about and build software that allows developers to create more software better and faster. So I often consider developers are often my customers (for example, the WiX toolset).

Now it is important to note that all of the data I've presented so far is in priority order. Ensuring the productivity and happiness of end users is most important. Next it is important to help developers build better software for those end users. Finally it is important to help developers built software faster. Faster does not trump better and the end user's needs trump everything.

You will see me get extremely frustrated when software or developers (who create software) do things that disrupt end users.

The same goes for processes that do not provide progress toward customer benefit. So back to the week after PDC05, where I returned to see our team mired in reverse integration hell. Larry Osterman talks about the Windows reverse integration process in his blog. In our case, the parent branch was not building correctly therefore our branch was not allowed to send our code fixes up to the next level. This means that whatever bug fixes we had in our branch (and there were a bunch of key fixes) were not getting propagated to the rest of the Windows organization.

Remember, I'm a "platform guy" and I happen to work on a "platform team" (inside Windows). That means our code enables developers (in Windows) to build features for end users. Bugs in our code prevent those developers from making progress in their code. If you read how excited Larry was when his code was reverse integrated (he wrote a whole blog about it after all), you can imagine how much fun it is to have people in other branches saying, "We can't reverse integrate our code because your code doesn't work!" It is only more frustrating when you know that the fixes they need are trapped in your branch because your parent branch's build is "on the floor".

Eventually, we reverse integrated and then started the next round frustration. Our team has a rotating "build facilitating developer" affectionately referred to as "BFD". The BFD is responsible for launching and watching the builds for the shared parent branch and fixing issues as they come up. Being BFD can be extremely randomizing so a single developer is only in the position for two weeks before it moves to one of the other teams to manage.

This is where the context switch costs come in. Imagine you have a process that you have to check in on every couple hours to make sure it is okay. Every third time you check, there is about thirty minutes of work you have to do. How much focused work do you think you can actually get done in a day? It isn't much. The time it takes to refocus from one task to the next just digs into your productivity.

Now while I was acting BFD there were still more emails coming in saying, "We can't reverse integrate our code because your code doesn't work! You need to debug your failure in our branch!" Remember, those branches don't have the exact same code that I have in my branch. So they may have bugs that I've already fixed. But someone on my team has to debug them again to be sure. Usually debugging goes a lot faster because we recognize things along the way. However, sometimes the fact that we've debugged this issue in a slightly different way gets us confused and we have to stare at it for a little longer until we realize this is the same issue we fixed twenty three days ago.

Now for the icing on the cake. In the middle of all of this, I got the following email from a Group Test Manager. This is a manager that has about three layers of Testers under him. So he's a decent ways up there. He includes on this email my Group Program Manager (who has about three layers of Program Managers under him) and my Development Manager (who happens to be my direct boss but also has two layers of Developers under him) and my Test Manager (who has two layers of Testers under him). I note these layers of management only to set the stage that this was one of those emails where you know the sender thinks you really need to do something.

Here is the email "in reverse-Outlook-order" (aka chronological order).

-----Original Message-----

From: GROUP TEST MANAGER

Sent: Wednesday, September 28, 2005 4:54 PM

To: Rob Mensching; Bug's TEST MANAGER; Rob's TEST MANAGER

Cc: Rob's GROUP PROGRAM MANAGER; Rob's DEVELOPMENT MANAGER; Bug's TESTER

Subject: Bug ### - Winmain code coverage builds fail to set up

Rob, please take look at this Test blocker bug. It will be reviewed tomorrow in the LH Ship Room. We need to know what the ETA for a fix is on this bug.

-----Original Message-----

From: Rob Mensching

Sent: Wednesday, September 28, 2005 6:47 PM

To: GROUP TEST MANAGER; Bug's TEST MANAGER; Rob's TEST MANAGER

Cc: Rob's GROUP PROGRAM MANAGER; Rob's DEVELOPMENT MANAGER; Bug's TESTER, Rob's DEVELOPER PEER

Subject: RE: Bug ### - Winmain code coverage builds fail to set up

I don't have an ETA. We don't really understand anything about the bug right now. DEVELOPER PEER is actually probably farther along in the investigation than I am at this point in time.

Note: I have 3 or 4 blocking bugs on my plate right now. I'm not sure if this is higher priority or not. I'm going to guess that you're going to say that this blocks all of Windows Test and thus is higher than making sure other teams are able to RI. Let me know if this is the case... and I'll juggle the bugs again.

Maybe we need a sev "-1" for more severe than sev 0. <sigh/>

-----Original Message-----

From: Rob's TEST MANAGER

Sent: Wednesday, September 28, 2005 6:53 PM

To: Rob Mensching

Subject: RE: Bug ### - Winmain code coverage builds fail to set up

Importance: Low

You rule.

The original email reached me at the peak of my frustration. Here was some Group Test Manager telling me how to prioritize my bugs and demanding an ETA on a bug that was, IMHO, clearly less of a problem to solving customer's needs than the other things that I was doing.

My Test Manager's private response (the last part of the email thread above) was what finally turned my frustration levels around. He made it clear to me that what I was doing was the right thing and that the expectations presented in this thread were unreasonable and unnecessary. Possibly even more important, he liked my style. <grin/>

Today, I'm operating at a tolerable level of frustration but I'm still not at the ideal. I may revisit this topic in a while but right now I need to head out to the Microsoft fields where I can burn off some of this frustration off in some flag football.

Comments

• Anonymous
  October 22, 2005
  The comment has been removed