A reset does not mean everything was thrown away

by Michael S. Kaplan, published on 2005/10/16 16:39 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/16/481625.aspx

When we hit the reset button for a video game, we do not throw away the game. We do not forget what we have learned, either. I thought about this very very recently....

Dare Obasanjo reposted a comment to mini-Microsoft that makes me wonder why the whole issue is so black and white to some people.

I mean, everyone knows that Cairo is a project that never shipped. But those who were there (and others!) know how large parts of what was Cairo still made it into products.

And everyone knows that the database project called Omega was a worthless piece of something that never shipped, But those who were there (and others!) know how large parts of what was Omega made it into Access and Jet.

(There are many other examples, but I wanted to get to the point -- feel free to fill in examples you may know of!)

Now everyone knows that the original version of Longhorn that was shown off at the PDC a few years ago was one that prominently featured Avalon visuals and Indigo and WinFS and so many managed interfaces around what previously only sported unmanaged ones. And everyone knows about the "Longhorn reset" and how it pretty much did cause the project to start over from the Server 2003 code base.

HOWEVER, the one thing everyone knows (but never mentions in the context of arguments from mini-Microsoft and others) is that a ton of the work that was done in that old Longhorn tree is still going to be released.

They also do not point out that the refactoring is letting a lot of it ship downlevel, too -- things like Avalon and Indigo and WinFS. This is something that was clearly not part of the original plan.

People talk about OS updates as if they ought to happen every couple of years. This was easier when they were two entirely different teams working on MS operating systems (the Win9x team and the NT team), but has proven to be a lot harder in the post-9x world. Yet no one seems to want to notice that OS releases from each group used to indeed take that kind of time, the kind of time it is taking. It is too easy for the pundits of the world to denounce changes and resets to get a lot of hits in an article, or for others to go on about the lack of accountability of execs who were involved.

If I do well on my review or poorly, if I get tremendous bonuses or nothing but cost of living increases or worse, NO ONE KNOWS other than those I tell or those who are in my management chain. So if execs were punished for waiting too long for the reset, how on earth would we know? They certainly would not tell me, as I do not know any of them personally and none of them report to me. And they have even more reason than I do to keep such things private and not share with those who will tell the tales, given the way the online press will latch on to anything to get more viewers.

I know developers at Microsoft who jokingly used to call the old Longhorn plan as another Cairo, to which I suggested that perhaps that was more of a Cairo.Net. And they laughed and did not disagree.

But people are not saying it now, about the Vista direction -- and those developers who made the original claims were not surprised by the reset, or by the adjustment. And they were not surprised by the fact that we are seeing so much of the technology that was "lost" stuck into Vista and into downlevel Windows as well. Because THAT is how Microsoft works.

The trouble I have is that there are so many people who understand every single point I have made in this post and even agree with most or all of it, but do not look at all of the points at once....

We are seeing more than ever before, and we are showing so much of it in public. So why are we not learning?

I think one of the biggest problems is that people see every line of code that doesn't ship as some sort of waste. Certainly, I would if I were the one who spent the past couple years writing some feature that never makes it into a shipping product (such as OFS).

However, look at MSR. These guys design things and write code all day with no expectation of any of it shipping. Perhaps it would be more useful to consider Development to be Research and Development; what ships is Development, while what doesn't is Research. They didn't waste 8,000 man-years on something that didn't ship -- they spent 8,000 man-years doing valuable research to avoid shipping a product that wouldn't work.

Seems that Microsoft is similar to most bureaucracies in that very few people, if ANYONE, ever has the complete picture. And, the further down the pyramid one is, the less they will see of the “big picture.” That being said, I think that program development (OS or otherwise) follows the path of many engineering or scientific projects that have to deal with unknowns. A lot of effort and heart is poured into finding ways of doing something that has not been done. Logically, there will be countless aspects that will not be incorporated into the specific deliverable – especially in version 1. However, things not initially used may have considerable value for other projects.

Technically, there is possibly a theoretical basis for differentiating between research and development. However, in many real-time development projects it would require a divergence of valuable resources and would require evaluating the steps AFTER the fact – and even then there would likely be defensible arguments for items to be classified as both research and as development. Of course, there is potentially a wealth of information to be gained from such analysis. Perhaps it could be used to motivate and reward the developers (errr … would that be the would-be-developers that ended up as researchers?) It could also be used by marketing and PR to help assuage the frustrations of the stone throwers. Yes, it is easy to lob missiles when we don’t have the big picture. And, who’s inclined to invest the effort of researching the process to find out what really happens???

In fairness to developers, researchers and engineers (add other professions as appropriate), I believe that they KNOW that there is intrinsic value in their processes, the knowledge that they acquire along the way, and the features, processes and formulas developed whether or not they are included in the “specified deliverable.” For many, it is incredibly rewarding to see someone else run with one of their concepts. Thankfully, (hopefully) Microsoft has a preponderance of people with such a philosophy.

Waited until this was lower on the page...

You and your friend knew that Longhorn was going down. That the plan was unworkable. Yet you fall back on the old canard 'the future is unknowable! no one knows!'

I respect you Michael, use your intellect here. The plan was unworkable. Who didn't communicate that?

First of all, some teams caught on to the 'game'. I guarantee each team delivering for Longhorn thought their schedule was tight but not as bad as some other team's. And I guarantee that scheduling concerns were brought up - I know in my team I repeatedly pointed out the unrealistic scheduling. So Management at the GM and VP level all had enough information to know that the schedule was unrealistic.

OK, so did that get communicated upward? Did these middle managers coax their view? Let's say that enough of them brought it up.

Now you have the senior leadership, Allchin/Gates/Ballmer. They felt compelled enough to trumpet "Big Bets! Big Bets!". CLR and WinFX. Make it so.

So when it became absolutely clear that, for example, the new Shell couldn't possibly be built on WinFS as it existed in 2003, what happened? A bunch of deck rearranging that lasted a year until someone pulled the plug.

Now don't you think that was bad planning? The decision to delay Longhorn, the decision to make big (bad) bets, the decision to be feature driven instead of date driven. That was a bad plan. It was a bad plan advertised at PDC as though it was reality.

You almost grasped the point when you said it was "easier" in the Win9x world. Smaller bets, date-driven releases. These work but don't give the company the innovation reputation. Longhorn was a supposed to be a Big Bang release. They will still trumpet the new release as bigger than Win95, but it will not be nearly as close in terms of improvement or impact.

So the big decision was made to stick with an untenable schedule, and everyone knows this. They might as well have just planned to 'throw one away', as that's what happened.