Geeks With Blogs
Amusingly MOSS ...It's funny how difficult some stuff is when it really shouldn't be

Deciding whether to implement a new, unproven widget to save in development costs is a lot like deciding whether to call a player who goes all-in on the first hand of a poker game.  You may land your cards, but is it really worth it?

The way to determine whether or not to take the risk with an unproven widget is a lot like how a professional would assess the scenario I just described.

An accomplished poker player knows what each hand is worth, not only in terms of the potential winnings, but in terms of how his invested chips will sway who has what equity in the game.

This same accomplished poker player will tell you that a big, early chip lead doesn't amount to anything worthwhile.  In fact, if you were to double up on the first hand of the game (implying that you eliminated another player to do so), you'd end up with far less equity in the game than the face value of chips you have in front of you.  This loss of equity occurs because someone being eliminated this early in the game is far more valuable to all players than the amount of chips you won by eliminating him.  You won his chips, but everyone else won the benefit of having a player eliminated, and they didn't have to risk the farm to do it.  Chip-for-dollar, your chips are now worth far less than everyone else's.

Now, let's apply this idea to systems design.  When your tech lead promises that a widget will make the development life-cycle easier, it's always at the cost of configuration, maintenance, and/or other no-see-ums that add up very quickly come delivery time (and to top it off, they are never documented adequately, if at all).  In other words, since he can't account for the the total cost of ownership (TCO) of the widget when he proposes it (hence it being unproven), he would accept the widget as a viable solution based solely on its perceived benefits without regard for the no-see-ums he'll have to wrangle.

"Saving" on development time with an unproven widget is a lot like winning that huge pot up-front.  While you save in development, someone will pay for the ownership of something duct-taped together, and if you're a vendor, it will inevitably be you.

So if you are going to take a risk with an unproven widget, do yourself a favor and build an inordinate amount of time into your project plan.  I mean on a factor of 4x of how fast you think you'd get it done if you were stoned, and had a mountain of cheesy poofs that demanded to be eaten.

Posted on Saturday, February 7, 2009 9:15 PM Other Stuff , Systems Architecture and Design | Back to top

Comments on this post: Systems Design and Poker Odds

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Adam McKee | Powered by: