Chandler's Schedule

Not surprisingly, one of the most common questions I get is when will Chandler be ready. Our original standard answer goes like this: We will first put out code for developers to look at by the end of the year. It will be an extremely partial alpha. Optimistically, we could have a 1.0 by the end of 2003. Pessimistically, it will be 2004. I've never been entirely comfortable with this response, so this is my chance to dissect the issues surrounding Chandler's schedule.

Software, like construction projects, is typically late, sometimes very, very late. It typically takes longer and is much harder than any estimates. There are, of course exceptions, like the original version of Lotus 1-2-3, which shipped exactly on time, and there tend to be exceptional reasons why. In the case of 1-2-3, it was implemented almost entirely by one person, Jonathan Sachs, and it was the fifth time Jon had implemented a spreadsheet. Not only did he know what he was doing, but he had enough experience to accurately estimate how long each part of the coding would take. This was one of the keys. The other was that we had a relatively precise idea of the feature set going into the product. In other words, we both knew what work had to be done, and how long each piece would take. It was possible to roll up the schedule from the bottom up.

With Chandler, it its current state, we don't yet know how fast we're going to be able to go, nor how far we have to get to the first release. This is not so much a matter of poor practice as it is reflective of the early stage we are in. The developers have just started to write production code, which is to say, enough decisions have been made about the fundamental building blocks of the product and how they will be put together, to start to build the actual product. Once we have perhaps three months of development under out belts, it will be possible for the first time to predict our rate of progress. To the extent that the specific tasks to be done have been identified at a fine enough granularity to estimate completion times for each task, it becomes possible to develop more or less reliable schedules using a bottom-up approach. That's the goal, and until then, the most accurate summary answer about a schedule is "we don't really know".

As to the absence of a spec, I think it turns out to be a virtue at present. The features are grounded by a set of commitments (e.g. the preliminary feature list on the web site) which should be thought of not as sketches, not blueprints. What is really thrilling is the depth of thoughtfulness and creativity on OSAF's design mailing list which has ensued. Thank you, participants. I've been reading the 30-50 daily comments and have been truly impressed. I can guarantee the design list will have an enormous impact on the product itself, and I'm hopeful we will have on board very shortly the new staff who will coordinate and distill the conversations there.

Of course, I haven't gone into all of this blindly. I know just how hard it is to ship a fully competent product. Fit and finish issues alone are always incredibly time-consuming. The last 10% of the product can take 50% of the total time. There will necessarily have to be a series of releases over a period of years in which the product will mature. One of the key tricks is in proper sequencing -- teams should build on a firm foundation before trying to erect the shell of the structure. However, if the foundation and shell are secure, some of the rooms do not need to be built out before the occupants move in.

Also, if Chandler is good enough to do what people do currently, and there is a painless migration path, it only takes a handful of killer features to make a great first release. The delay in some or even many of the advanced and specific features for a PIM will no doubt frustrate some people, but if can establish credibility as to the quality and rate of progress, I am guessing most people will give us a break on this.

Another schedule variable has to do with how soon and how effectively development by volunteers can take place. It's an old saw that no matter how many men you put on the job, it still takes nine months to make a baby (and let's not forget the hard work is done by woman). Originally I had not counted on more full-time or most full-time volunteer developers, but it is beginning to look like we'll have some on the team, which is fantastic news. It gives us some choice about moving more quickly vs. having a wider scope for the first release.

One area we are rethinking, based on input from the mailing lists and other sources, is whether also build Chandler from the outset to support large organizations, not just small-to-medium ones. There may be an architecture and protocols which reduce the amount of work to do both to less than the 2x effort I had imagined.

Posted by mitch@osafoundation.org at November 14, 2002 08:26 AM