Chapter11.Scheduling

Chapter 11. Scheduling

This is, of course, where the trouble really starts, because the average software development manager thinks of his schedule as a working document, and his general manager tends to view it as a contract. This "subtle" difference has accounted for lots of grief throughout the years.

This has led to the infamous "two-schedule" game, whereby there is an "internal schedule," purposely held tightso the developers don't use up all the time they think they haveand an "external schedule" for the rest of the company, which has the safety margin added on to the internal schedule. Frankly, I've never been a big fan of this ruse. It is hard to keep the two schedules from becoming known, and once that happens, neither schedule has much credibility, no matter how hard you try to explain that one is the "development schedule" and the other is the "business schedule." My recommendation is to have one schedule, and have that schedule have as much integrity as possible.

In the end, a general manager has a difficult time trying to reason with a software development manager about his schedule. In a similar vein, it is often hard for the software development manager to intelligently discuss one component's or one subsystem's schedule with the technical lead for that piece. The reason is that there is very little to grab on to. Sure, you can start discussing whether this or that could be done faster, but ultimately it is a matter of judgment, and it is rare that any one piece is very badly estimated. In point of fact, the weakness in all scheduling activity comes from two principal causes that crop up over and over again in software development projects. First, there are interdependencies that are unknown or unclear at the beginning of the project. What tends to happen is that one part starts slipping, and other pieces start slipping in the background because their developers are waiting on the heretofore-unknown critical component. Only after the secondary components show slippage, too, is the dependency discovered.

A really good antidote to this form of schedule slippage is iterative development. In the early iterations, putting together the big pieces to get the first example of a working system will flush out these "hidden" dependencies. Once it becomes clear, various strategies can be employed: forced decoupling, more attention/resources put on the critical piece, and so on. Another way to mitigate this problem is to ask each team to iron out its subsystem interfaces well in advance of implementing the internals. That way, other groups can continue to make progress based on the published interfaces. So long as the interfaces remain stable, or mostly stable, the internals can change quite a bit without causing too much pain.

The second and more insidious reason that software development schedules slip so badly is that they do so gradually and progressively. Fred Brooks pointed out many years ago that projects get to be a year late one day at a time. If you miss your first milestone by a week or two, it is most likely that you will never make that time up and will slip all succeeding milestones by that much or more. It is the proverbial death by a thousand cuts, and even with the most assiduous management, it is difficult to avoid. On the other hand, if, as a software development manager, you do take your eye off the ball, well, look out!