Scheduling a software project

For the first 6 years in my career I have not heard the word 'schedule' once.

I was working at Bentley System then, starting as a new graduate and working my way up to the founders's team (not in a sense that I became one of the founders, of course; but they were active developers, and they worked on fun stuff, and I was working with them). There weren't many schedule reviews - most of the top managers in the company were engineers, and preferred to learn the state of the world by actively contributing the code. In particular, the founders worked on every new project that the company started.

Then I moved to Windows CE team at Microsoft, and for the first 3 years there I have not heard much about schedule either. This despite the fact that I became a dev lead almost immediately after joining the team. Later on we started drawing boxes in MS Project, but this was mostly to keep track on who works on what. There was not an attempt to hold individuals to a date.

The same was true in my next job as a dev manager in an incubation team. We did have the schedule, and it was my job to make one, but it was a tool to help us track where we are. It was never a goal to 'hit the schedule'.

When I moved to Windows Home Server, it was a different world. Being a consumer product, there was a huge incentive to have it ready in time for Christmas shopping season - consumer electronics stores make close to 70% of all their yearly business during the three months leading to the New Year. If you aren't ready for Christmas, you might as well skip the release altogether, and wait for the next year.

In economics, there is a well known truism that a country cannot have fixed exchange rate, free flow of capital across its borders, and a monetary policy all at the same time. One can have any two of the three, but not all three.

For example, suppose the government has pegged exchange rates to a big currency (the dollar), let's say the flow of capital across the border is not restricted. The way the government usually conducts the monetary policy (which is a way to use government's control over money supply to influence the economy) is by setting the interest rates. Let's suppose it sets the interest rates above that which is set by the Fed.

Well, it would be an arbitrage opportunity - someone can borrow an infinite amount of money from the US paying the Fed interest rate, move it into the country with the higher interest rates (free capital flow!), and make the other government pay the higher rate. Because the exchange rates are pegged, there is no risk - we're making something (a difference on interest rate borrowed and paid) for nothing.

An arbitrage is ability to make non-zero amount of money from nothing, and without risk.

In no time you will find enormous mass of the capital streaming into the poor country, wiping out its resources, and transforming them into huge bonuses on the Wall Street.

Well, the software equivalent of this principle does exist, and it goes as follows - it is impossible to have fixed release date, fixed feature set, and product quality all at the same time. This of course is true for relatively big projects - I can predict precisely how quickly I can write a "hello, world" program, and it will do exactly what it needs to do, and be bug free.

But most of the time in this industry people are working on a bunch of interdependent features, and the code is based on a very rich platform. At the time of estimation, the environment (the dependencies below and to the side of your project) are not known, and a lot of times the information about the interfaces at the top side of your project (customer requirements) is incorrect. Add to this other eventualities - an engineer getting sick, or a key resource on another team going on a month-long vacation in Nepal, and you will understand why predicting the schedule, given a fixed feature set and quality, is an NP-complete task.

Of course if you're interviewing a project manager, he or she will never admit this. The standard solution people use to address this problem is pad. Add 10% for the meeting tax, 10% for expected sick days, 20% for reengineering, 30% for unknown customer requirements.

The problem with padding is the net effect of it is almost always huge - doubling or tripling the originally estimated project time. Plus you don't really know how many sick days you will really take, and how many new customer requirements will be discovered en route. So the result of padding is grossly overestimated schedule, that is about as useless as the original underestimated one.

Because if the problem with the underestimating the schedule is that you will miss it, the problem with the overestimating it is that you will either cut the features that did not need to be cut, or quote your customer a price that will be beaten by a competitor.

There is another insiduous side to overestimating, and it is that you cannot fool your people. Let's suppose a developer quoted you a week for a particular task, and you, the manager, has padded it by another week. Well, the dev now has 2 weeks on his schedule, and because he or she is absolutely sure that the task is doable in just a week, the first one will be spent browsing the web or playing Sudoku. And then the dev will get the flu and miss the schedule anyway! I am quite convinced that this phenomenon is very common, because in my career I have seen many an overblown schedule be missed anyway.

So with this in mind we have set out to build Windows Home Server with the understanding that the time is very important, as is the quality - so we will compromise the feature set - everything that cannot be done by the time we need to ship will be mercilessly cut. The quality and the date will be held firm.

This sounds fantastic on paper. In fact, I read and re-read the last paragraph, and I absolutely love it. We were so smart! Why didn't anyone figure this out before us? There must be a Nobel prize in project management in it!

The problem here is that usually the features that make up the skeleton of your project have enough variability in and of themselves that make cutting secondary features a very moot point. In reality you don't have enough time to do what absolutely needs to be done for the project to ship. So in reality, it is the feature set that is fixed, and the real trade-off is between quality and time.

And that was exactly the tradeoff that happened in the run-up to the release of Windows Home Server.

So what lesson did I learn from all this? I think that fixing the date leads to crappy quality, and that it is better to take the Halo route - the game is ready when it is ready, even if Bill Gates tells you otherwise. So now I am back to working on projects that are quality, not release date driven.

Disagree? Post a comment to the contrary, and get yourself employed as a project manager for the next version of Windows. Microsoft will pay millions if you can get it ship in time and on quality. :-)