Tuesday, April 14, 2009

When Good Enough is Good Enough

I just came off a project to select a new enterprise-level solution for the organization. The exact product and purpose are inconsequential in this case, so instead I'll just focus on one of the more interesting aspects of the decision process.

In other posts I've discussed the value of having IT professionals who look beyond the first answer they find. Some of our siblings in this field accept the first workable solution at which they arrive without considering alternatives, without pushing for an elegant answer that solves all of the known requirements, plus positions the business for the future.

In the face of that line of thought, (and the tenacity with which I advocate the position), it may surprise some of my readers to hear me argue that sometimes, good enough is good enough. Sometimes, we knock ourselves silly trying to find the perfect product, or perfect code when acceptable solutions are right at hand. Imagine arguing over two sports cars, one which will reach 135 miles per hour, the other able to reach only 130. Both have leather interiors, XM Satellite Radio, both are sleek and sit five comfortably.

One faction of evaluators believes that the extra five miles per hour could be important in a long race, on the straightaways. The other faction finds the slower car to have a more refined style. The selected car will be driven on US highways, where the top speed is about 85 mph. The car that will hit 130 is, frankly, good enough. OK, that was an easy one.

You're asked to pick between two market-leading products that will provide... Stop! Did you catch the key phrase in the preceding sentence. Both are "Market Leading." Exactly how cutting edge is your need such that the "B" level product is a bad choice? We get entirely too wrapped up in the differences between technology products that we often miss that the business doesn't care, need to care, or want to care. Consider the graphic to the right. Notice the apparent disparity between the two products based on the delta in bar height.

Based on this comparison, one could see why choosing product "B" might cause some concern; it is clearly inferior. This graph illustrates the danger in focusing too closely on details, and why improper analysis can mislead the analyzer. Note that the horizontal axis does not start at zero, which it should. The proper graphic illustration in this case is displayed to left. I actually saw a U.S. President use this misleading technique to make a case for legislation. I yelled at the television for 20 minutes and he never backed down.

We tend to exaggerate the significance of minor differences and that tends to delay decisions, actions, and productivity. Here's a key - if you are inventing an solution, say writing code or building a configuration; take some time to work through a couple of solutions. Compare and contrast, especially if you are not following an established pattern. If you need a Factory Pattern, or a Singleton, just build it using established templates and move on. If what you're creating is new or novel, then take some time to make it elegantly simple.

If, however, you are choosing between the top two or three existing solutions, don't sweat the petty things and don't pet the sweating things. This is especially true if you are comparing the top solutions in a given market space. The term "diminishing returns" can be easily applied to elongating the decision process. In most cases, where the top solution providers are concerned, the details don't really make that much difference. Furthermore the leader in the market today will be leapfrogged by the challenger and round and round we go. Good enough is good enough. Make a choice. Move on.

Follow by Email