When “Good Enough” isn’t Good Enough

So what is this picture? The unhelpful answer is that it is a photo of a sign with a burlap sack on it. I’d like to say that my community thought it would be a cute Halloween decoration, but I cannot. The truth: it is great example of the “good enough” anti-pattern.

Pulling the curtain back a bit further, I can tell you that there are legions of these in my neighborhood. Many months ago, road construction required some long term rerouting of local traffic flow, so a large number of detour signs were installed. Still months ago, the construction completed and the signs were no longer needed. The correct solution was to remove the signs; the “good enough” solution was to cover them with burlap sacks. It was, no doubt, quicker and cheaper: it solved the immediate problem.

As architects we frequently face “good enough” solutions employed to solve an immediate problem. Just as frequently, once the “pain” of the immediate problem has been relieved (or even reduced), the interest in implementing the correct solution fades. We have some strategies for avoiding these situations:

  1. Strive for strategic solutions that meet tight budgets and timelines. Higher costs and longer timelines sometimes correlate with better solutions, but not always. Determining if a strategic solution can be implemented for the same (or close) impact requires that the project employ math to compare the cost and timelines, not emotion. The gut reaction of almost every project manager will be to assume the strategic solution will cost more and take longer. We have all been a part of “good enough” solutions that – not surprisingly – took much longer than expected to implement.
  2. Probe the reality of the deadline. Frequently a “good enough” solution will be implemented to meet a deadline that is not as immutable as it seems; a deadline which shifts multiple times through assorted scope modifications. This can result in a spaghetti mess of a solution after spending more time and money than would have been spent doing it right from the start.
  3. Help the decision makers understand the facts. Nothing is free. A solution cheaper than the strategic solution is cheaper for a reason. The project will carry more delivery risk, the solution will skip functional and non-functional requirements, or the enterprise will be less prepared for future technology needs. A business can always choose to make choices like this, but they need to be conscious choices.

None of this is to imply that there are not situations where a “good enough” solution is, well, good enough! The analysis associated in 1-3 above will identify those scenarios.

It is also critical that these non-strategic design choices be documented. We will also share some additional strategies for documenting and managing these non-strategic design decisions in a future article.

With regard to the burlap solution, I will keep you posted and share the outcome when one of the sacks blows off and unleashes a phantom detour…

Dan Hughes
Dan Hughes is a principal consultant and partner at Systems Flow, Inc., where he leads the technology services practice. He has 20 years of software engineering experience spanning a broad range of technologies and techniques. Startup to enterprise, he has launched, managed, and executed all aspects of both product and enterprise life cycle, delivering complex, enterprise-scale architectures for clients in the public and private sector, in industries ranging from banking and insurance to international development. Dan holds a Bachelor of Science in Computer and Systems Engineering from Rensselaer Polytechnic Institute. For more details, please visit Dan's LinkedIn profile
Dan Hughes

Latest posts by Dan Hughes (see all)



Comments

Comments are closed.