Avoid 3-Card Combinations

I used to play collectible card games.  I attended Whitman College during Richard Garfield's tenure there as a math professor so I got into Magic: The Gathering near its inception.  For those of you who don't play these, the basic system goes something like this.  You buy packs of cards--not unlike baseball cards--which you trade and assemble into decks.  During gameplay, you draw cards from your deck and place them into play.  The rules for playing them differ from game to game but they almost always involve text on the cards that explains their behavior.  The abilities granted by each card vary greatly and they are most powerful in the way they interact with other cards. 

Sometimes you can find combinations which are nearly unbeatable.  If the game is well designed, such killer combinations usually require get 3 (or more) of the exact right cards.  Most of the time you can only have a limited number of any one card in a deck.  Economics often precludes it even if the rules don't.  Thus the chance that you will have the 3 cards you need in your hand (or in play) at the same time is very low.  When we were playing, we had a saying that went something like "don't build your deck around 3-card combinations."  While these killer combos were game-winners if they came out, they were so rare that you usually lost.  A much better strategy was to build a deck around simpler concepts that required only two cards at a time to pull off.

That's nice, but what does this have to do with computers and programming?  It is a good analogy for the way many people manage projects.  If you consider each dependency as a card you need to draw and shipping as the killer combination, it becomes obvious that the winning strategy is not to take on too many dependencies.

If you assume that the new framework or programming language will be mature enough and that your maintenance work won't take very long and that the team you're relying on will deliver their part on time, you've just built your deck around a 3-card combination.  Sure, it will be a spectacular product and take the market by storm when you ship it.  If you ship it.

The world of software development is full of math people.  You'd think we would pay more attention to the probabilities of success.  Somehow we think we are in a reality distortion bubble though.  Math doesn't apply to us.  Sure, it will be hard, but we're better than average.  Things will fall into play.  We'll live happily ever after.  Except, we don't, it does, we aren't, they won't, and we won't.

The moral of this tale:  Try to accomplish a little less and build on last year's framework.  Your work-life balance will thank you.  So will your marketing people.