Schedule Blackjack

Most people know the rules to the card game Blackjack (also known as TwentyOne?). The player attempts to have the total of his cards be as close to 21 as possible, without exceeding 21. Player is dealt two cards (whose total can never exceed 21; aces are worth 1 or 11 at the player's option; face cards 10, 2-10 cards the number indicated) and then has the option of requesting more ("hit me") or standing pat ("stay"). Each additional card is added to his total; when he stands pat the dealer does the same thing (though the dealer has no choice whether or not to hit or stay); whoever is closest to 21 wins.

If the player exceeds 21 (busts), however, he loses his bet immediately and is out of the game. Even if the dealer subsequently busts himself (the dealer plays several bettors at once), it doesn't matter. If all players save the dealer bust, the dealer doesn't even need to show his cards.

The above is a gross oversimplification, of course, but it is necessary to explain the title of the scheduling AntiPattern hereby deemed ScheduleBlackjack. (ScheduleBlackjack occurs primarily when developing a project schedule, and can be applied at both the macro (whole-project) level and micro (individual task) level. In ScheduleBlackjack, the following rule applies:

Provide whatever estimate you like; but if you slip (even by a day), you lose.

In other words, the penalty for over-estimation (coming in early, even ridiculously early) is non-existent or light; the penalty for coming in late is severe.

This is an usually AntiPattern because:

• Leads to excessive amounts of SchedulePadding, as developers (and the team as a whole) adjust their schedules such that the probability of any slippage is (they think) near zero. (Sometimes, the padding isn't enough). This leads to inefficient allocation of resources, and may make a doable project seem not doable.

• Some times, coming in early is as bad as coming in late (though the end result can be delayed in an early case).

• Difficult to predict when something actually will be done. The schedule is no longer a good-faith estimate, it's a worst-case scenario.

In some cases, this might be legitimate when applied to a whole project, and there is some externally-imposed HardDeadline? that must be met; failure to meet this deadline is a catastrophe. If this is true, the deadline, its reason, and the consequences of failure should be known by all. ("Because the boss said" and "you'll all be fired" are not, by themselves, legitimate reasons/consequences for the purpose of this discussion.)

When applied to individual tasks (which often have greater variance) is almost always a bad idea.