A Parable on Fake Release Dates

One January, the DysfunctoSoft Veeps of Product Management and Engineering got together and decided the date for the next product release.

Did these Illustrious High-Ups take into account how long it would actually take to develop the features they want? Hell no. They picked a date that would keep them from getting in trouble with the CEO.  A date approximately 8 months away — in August.

THEN, because DysfunctoSoft had a long and perpetual history of never completing a release even close to on time, the Veeps told Engineering that the release date was a mere 5 months away — in May. And they goddammit they meant it: Come hell or high water you frakin’ engineers better finish this release in May or the CEO will shut down our division.

Why the lie?  Why the empty threat? Because if those indolent engineers knew the actual date was August, well then the release wouldn’t really be done until November. Or so the thinking went. Gotta hold their feet to the fire, those untrustworthy, lazy engineers.

Next a sham schedule was produced, one that required all design be finished by end of January, coding done at end of March, beta testing starting March, and the final release in late May.

Somehow (and no one has any idea how this happened?!?), the engineers didn’t fall for it. Maybe they remembered that NEVER before had DysfunctoSoft shipped a release within 6 months of the originally stated date. Maybe the engineers recalled that in every prior release, the Veeps lied to them about the actual “drop-dead” date for the release.  Maybe they saw that the schedule jammed over 8 months of work into just 5 months, figured it was impossible and just gave up.

So May passed, and then August. It was November before the release finally shipped. Three months after the “real date.” Six months after the “fake date”. The Veeps were so glad they said May was the fake date because if they had said August then the release wouldn’t have come out until February!  Or so their thinking went.

(Note: If you are having trouble following this, you are not alone. Written clarity sometimes eludes the Cranky Product Manager, so refer to this diagram).

Then it was January of Year 2. Time again to plan for the NEXT big release. The Veeps met, and again picked a “real” release date 8 months away, in August once more. Recalling that the release slipped 6 months past the “fake date” last time, they figured this time they needed a “fake date” in February to make the “real date” in August.

And so the developers were presented with a sham schedule showing eight months of features being designed, developed and beta-tested within 2 months.

And the release proceeded much as any rational human being would expect. Yup. The release came out in November – a full 9 months after the “fake date”.  Once again the Veeps congratulate themselves on their decision to put out a fake date of February, because if they hadn’t, well, the release would be that much later!

So what do you think will happen in Year 3?

Well, the Cranky Product Manager got an 800 on that GRE section with the funky logic problems (if Tommy is sitting across from Alan, and Alan is sitting next to Donna, who is going to fetch the CPM a Starbucks?), so allow her to calculate.  For the next release to be actually completed in eight months, the “fake release date” needs to be 9 months earlier. In other words, the Veeps will have to tell their teams to finish the release one month prior to even starting!

That is, if this “fake date” crap even works.  Which, of course, the Veeps insist it does. It seems ingrained very deep in their psyches, as it is with many executives in the software industry. No matter how much evidence there is to the contrary.

What, oh what, is a Cranky Product Manager to do?

Be Sociable, Share!

• 
•