In many, if not all, projects there are a few key pieces of software technology, where much of the risk and the reward in the project are found.  These pieces are quite rightly subject to scrutiny during the initial architecture and design phases, where tradeoffs between the benefits offered and the risks presented are considered.  Problems arise when attempts are made to acquire the benefits of a new technology without incurring the risks, by moving the risks around while trying to keep the benefits initially under consideration.  I’m not talking about this as a rational behavior; rather I am focusing on the irrational behavior of assuming that if the risk can no longer be seen, it’s not there anymore.  This is more than an architectural or design anti-pattern, it’s a decision making anti-pattern.

Imagine this process as the old style shell game, where you try and guess which walnut shell is hiding a pea.  You bet your money, the ‘dealer’ slides the shells around, all the while keeping up a stream of patter and fast hand motions, and at the end you try to guess where the pea is hidden.  If you guess randomly, you’ve got a 1 in three chance of winning, assuming three shells and one pea.  If you’ve fallen victim to the dealer’s misdirection, you’ve very little chance of winning.  If the dealer isn’t even required to prove that there’s a pea under one of those shells, just that there isn’t one under yours, the game is truly rigged, you have absolutely no chance of winning.

Now imagine those shells to be the beneficial capabilities of software technologies, the pea being the risk of their use.  This does mean that most shells have peas hidden under them, but we’re professionals, so we’ll dispense with the risks we have recognized and dealt with before.  What we’re left with are the risks of the new and unproven.  We have a collection of shiny new walnut shells; with racing strips and chrome trim; and they all have peas under them. Peas with names like “Unproven technology”, “No Broad Support”, “Single Vendor Source”, and “No Experienced Resources”. 

During this process we are also being driven by externally imposed requirements, requirements with names like “Must do X”, or “Must not do X”, or “Must do X in Y amount of time”, or “The way X is currently done is utterly unacceptable”.  Where the shell game comes in is when the new technology is truly enabling, either by making something not possible before possible now, or by making something once difficult much simpler, faster, or both.  The new software technology claims to do X, which meets one of our requirements.  It’s also new and requires new skills, which earns it several epithets from the preceding list. 

Often the reaction to the requirement for doing X, prior to the arrival of the new enabling technology is “Forget about it .  Can’t be done”, but the new technology makes this position much more difficult to hold.  Responses from the outside stakeholders can be expected to cite the widely available marketing literature for the new technology, or the plans of competitors who are planning on using the new technology (more likely competitors trapped in the same shell game).  This makes it difficult to reject the requirement out of hand.  We need a new mechanism, where we can take all of the new capabilities we are being compelled to use, but accept none of the risks associated with a realization of those capabilities.

One characteristic of this anti-pattern is it’s reliance on group consensus, because it is affecting a high level group’s decision making process.  I’m sure many people reading this are laughing to themselves, knowing that they’d never be party to any shell games with a projects risk, they always know where the risk peas are at all times.  The goal of the anti-pattern is to make the risk disappear, most often by simply loosing it.  Many participants in the group simply become overwhelmed with the minutia of the techniques used to hide the risk, so that while each person knows that the risk is not in the areas for which they have particular responsibility, they also don’t know exactly where it is anymore.  So the group consensus becomes one of ‘Since none of us can find the risk, it’s obviously gone’. 

In the following series of posts I will discuss some of the common anti-patterns that occur in this effort of self deception, and will shine a bright light on where the risk has moved to when these anti-patterns are applied.  Some of the shell games I will cover are;

1. Reductio ad absurdum -  We don’t need the new technology – It’s software, we do software. Q.E.D.
2. Frankensteins Monster -  We can glue together several other technologies to gain the same capabilities.  This is merely a problem of composition.
3. Hope Floats - We’ll do everything else, and then do a follow on effort to add the new technology.