Fog Creek Software
Discussion Board




How do you meet your schedule dates?

Back in your column discussing the Microsoft PDC, you implied that you didn't have much faith that Microsoft would be able to stick to their scheduled release date for Longhorn. 

It seems like Microsoft, and most other software vendors are so notorious about missing deadlines that no one believes their target ship dates will be met.  Yet, from what I can tell, FogCreek has always met their ship dates (I could be wrong about this).

Could you let us know what the difference is?  Is it a matter of complexity or is there something about the corporate culture at Microsoft and other vendors that lends itself to missed schedules?

Paul S
Sunday, February 22, 2004

The MS-Office development teams at Microsoft have been basically hitting their schedule dates for over a decade. It's just a matter of being willing to cut features to make the date and being realistic about how long it takes to tie up a product after code-complete.

I've had many people tell me that they have hit schedules on the nose by using the "painless software scheduling" system I've described, even on 2 year development projects with dozens of developers.

At Fog Creek to be honest we solved the problem another way: we never pre-announce dates and we have no external requirements to meet any particular date. We don't promise certain things by certain times to certain customers; we don't care about rushing to meet a "competitive window" because we're in this for the long haul; and we don't have big marketing and PR campaigns which need to be scheduled long in advance. So we have had the luxury of never needing the answer to the question "when will this be done," something which most other development teams need.

As we grow, we'll lose that luxury. (Anyway, we should have more of a discipline about this than we do because decisions about ROI can only be made correctly with accurate information about what the cost of various things is really going to be.)

Joel Spolsky
Fog Creek Software
Sunday, February 22, 2004

And I should add that Microsoft is in a classic position of not needing to ship Longhorn on any particular date. They realize that nothing terrible will happen if they ship in 2007 instead of 2006, so they're not even pretending to have a due-date, which, as every college student knows, will make them take even longer. This is why I'm skeptical about their ship date -- not because I think they are notorious for always being late, but because they don't have a heck of a lot of incentive to ship on any particular date.

That said I don't think the Windows teams at Microsoft are very good at making dates because their debugging phase consists almost entirely of backwards compatibility testing, which is such a huge and messy problem with so many external depedencies that nobody knows how to schedule it. Hopefully by now Microsoft has been through enough cycles of this to schedule a little better. Also I have noticed that the Windows teams tend to take so long between major releases that everyone starts to think that if they don't get their pet urgent feature into this release of the OS it will be 5 years before it gets into the next release. So a lot more "one last things" get stuck into the product, and as soon as team A gets to slip by 2 weeks for their "one last thing" then team B will demand to squeeze their new 3 week "one last thing" into the newly available time on the schedule...

Joel Spolsky
Fog Creek Software
Sunday, February 22, 2004

Microsoft's Longhorn team not having a deadline doesn't necessarily make them take longer.  According to Peopleware, having no deadline provides for greater programmer productivity than having a deadline.

Troy
Sunday, February 22, 2004

There's a term for the effect whereby a task increases in length to exactly match the time allotted for it.

In other words, if you set a deadline, the task will rarely be completed before that time.

It's one word, like Jackson effect or something like that. Can someone remind me?

Nigel
Monday, February 23, 2004

Parkinson's Law?

http://www.geocities.com/Athens/Acropolis/8040/parkinson.htm

I've also heard of the "Student Syndrome" which seems to be connected...

fred
Monday, February 23, 2004

That's the one -- thanks.

Nigel
Monday, February 23, 2004

According to "Peopleware", Parkinson's Law almost certainly doesn't apply to software developers.

The book goes on to show studies where programmers with no time constraints have the highest productivity of all.  On the other hand, overly optimistic or tight estimates sap the programmer's energy, and the frustrated programmer doesn't work as effectively.  Apart from no deadlines all together, the more realistic the estimate/deadline the more productive the programmer.

Another point is that programmers under time pressure won't work better, just faster (ie. quality will suffer).

Troy
Monday, February 23, 2004

We had a very large project by our standards (45,000 hours) which forced us to revisit our estimation techniques.  We've been on time, on budget our last 10-12 projects since then, but there's a lot of upfront investment.
- We prototype every UI and design the architecture before any coding takes place
- We break all tasks down to 15 hours or less, ideally 8 hours or less. AKA Decomposition.
- We do test and dev in parallel
- The person performing the work estimates the time required, be it test, dev, functional analysis, etc., and gives high low and planned estimates
- People working on the project enter their hours (historical data) and at the end of each iteration in development, we share their actual times with their estimates, and analyze where there were discrepancies.  They then reestimate future work packages.  After a while, people get MUCH better at estimation.

There's a lot more just to estimation, but these are just a few things we've found to be helpful.  With good decomposed estimates, we can build a project schedule, balance the resources and come up with a good schedule from an hours and timeline standpoint.

Jim F.
Monday, February 23, 2004

*  Recent Topics

*  Fog Creek Home