WSJ on Longhorn engineering processes

JChung2006 wrote:

We'll see if the new process works.  Right now, I get the sense that it still hasn't gotten totally accepted and that Microsoft developers are still doing eleventh hour coding to get things done if only to meet arbitrary deadlines like Beta1, PDC, and Beta2.  It'll be interesting to see what happens to our C9 MS posters when it comes to crunch time and it's time to ship Windows Vista next year.  I've a feeling that their activity will drop off significantly in that timeframe.

We want Windows Vista to ship in 2006.  That means working back from that date and putting down various landmark dates like Beta 1, PDC release, Beta 2, RC0, RC1, RTM.

Thus, none of those dates are arbitrary.  There's a great deal of planning that goes into those dates, and a lot of teams build their events and schedules around those dates. 

There's a degree of buffering built into the schedule, but only so much before we get into day-for-day slips.

There are three things I care about for my team: quality, schedule, features.  And in that order.  I won't risk schedule for features, but I won't drop quality to make the schedule.

Of course, we find last minute layer violations (arrrrgggh! because they're a bear to fix and probably should be easier to avoid), or we spike bugs over cap at the last minute, or we really, really, want feature X to get in so we go for it, and now we are juggling schedule, features, and quality.  That's the 11th hour heroics I want - meeting quality, meeting the schedule, keeping the feature.

Cybermagellan wrote:

So the features aren't planned? I mean to the point where you know what has to go in by a certain time? No offense but this sounds like a management fault not so much a development fault at that point.

In a perfect world the features that are obtainable should be included into what is going to be the final product based on their time schedualing. Then that should be "announced" to the public and coding should go from there. After that when everything is all done then small little requested features should go in and get pounded out as time permits. Code freezes should happen and then final product should ship (Naturally after beta, rc, and RTM).

Well, as you say "in a perfect world".  I don't live in that world.  I live in a world where we plan features, and then they take longer or shorter to implement than planned, where dependencies cut what I need, where I need to respond to changes in the competitive landscape long after product development has started.

So yes, we have a long list of planned features.  I wrote a nice 15 page summary of our collective feature ideas back in August 2004 for IE7's UX.  That plus a lot more input turned into a set of Beta 1 features and Beta 2 features, which now has turned into a set of RTM features.  The list has shrunk over time, as some things turned out to be not such great ideas, and some things turned out to be too expensive (too much churn, or too much time needed) for IE7.

JChung2006 wrote:

If there is already buffering in the schedule, then arguably there should be no eleventh hour heroics since any such heroics would be using that extra time.

The thing about "buffering" is that management knows that development does this and usually has a set of features ready to request once development gets done with what they agreed to do in "real" time. 

When I said "buffering" I didn't mean "hidden padding in the schedule ", I meant "time allotted in the schedule to soak up a degree of error and slips".

As for your "developers" vs "managers" discussion, avoiding that is why individual contributors report to dev leads who report to dev managers like me.  Same for test and for PMs - you have to get to the functional group managers before the next layer of management isn't the same discipline.  In other words, devs reporting to devs keep everyone honest.

As the dev manager for IE's UX, I am the person who signs off on our estimates.  There's no secret padding upwards to higher management.  We create workitems from our specs, we estimate those workitems, we add some buffer for errors and the like, and say "Feature X is going to take 15 dev days to implement".   There's total transparency as to how that estimate was created.

In all honesty, I've seen too much of the "management won't tell the real deadline, dev won't tell the real estimate, everyone plays schedule chicken" game played, both at Microsoft and before I joined Microsoft.  It's crap, and I won't play it. 

Things like bug cap and the other quality gates make playing schedule chicken far more difficult.  There's just too many metrics, too much transparency, too many checkpoints built into the system.

Schedule chicken, BTW, is when you lowball your estimates or promise the sky, because you're betting that some other sucker is going to do the same thing, and he'll force a schedule slip before you do.