December 4, 2011
The Heisenberg Uncertainty Principle says that you can measure the position and the velocity of a particle, but the more precision you have about one measurement, the less you’ll have about the other. There’s a similar trade-off with software schedules. The more precision you want about the timing of the schedule (say, the feature-complete date), the less certainty you’ll get about what’s included in that release, and vice versa. This makes sense: although it may be possible to implement 10 features in 30 days, a programmer can’t commit to implementing all those features by that date. The more you want to hold him to the date, the fewer features he’ll be comfortable committing to. The more you ask to commit on the feature list, the less certain he’ll be about the date.
I saw two striking examples of this so far in my career.
At one company, for four years the director of engineering would say, “It’ll be ready when it’s ready.” We’d commit to a large set of features, but the release date was sloppy. We’d put out a rough schedule but it would slip just about every release. But the release was full of new and interesting features! This drove Marketing crazy. They wanted a firm schedule so that they could organize press releases, marketing splashes, and sales training.
The director of engineering left and was replaced by someone who caved in to Marketing’s pressure. We were able to hit our predicted dates pretty accurately, but to do that we had to drop all but the most basic, simplistic features and bug fixes. Almost nothing of interest was released my last year there. This annoyed Marketing too, of course, since they were then forced to promote a new release that wasn’t really all that interesting. It certainly hurt the product, the company, and its customers. I’m quite certain that customers would prefer to get a release a month later but have it include features they find useful.
The second example was nearly identical, but at another company. In Phase 1 of the development cycle (one month long) we planned a ton of features and got them all implemented, making a giant leap in the development of the product. We worked hard, late nights and weekends, and build practically a fully-working prototype. But we missed the deadline by two days, out of a month. The CEO publicly humiliated engineering at the company meeting, and the VP of engineering publicly humiliated the project manager at the engineering meeting. Schedule slips are unacceptable, they said.
What happened next is predictable: Phase 2 was scheduled extremely conservatively. The project manager wanted to be code-complete a week before the end of the month-long cycle, which meant really aiming to finish two weeks early, to allow for slipping. Well nearly nothing of substance can be accomplished in two weeks, especially since we were already two days into the cycle. Phase 2 and Phase 3 were released on time, but were empty. We fixed a few minor bugs and introduced one interesting feature. Management thought they had a project that wasn’t slipping, but in fact the whole project slipped a full two months because the programmers and project managers were too afraid to commit to anything substantial.
Upper management must accept that the schedule will be uncertain. Otherwise they risk shipping an empty product exactly on time.