CSC/ECE 517 Fall 2010/ch7 7g ms

Analysis Paralysis Anti-Pattern

Analysis Paralysis Anti-pattern

In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.

Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.

How to Defeat Analysis Paralysis

   *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge
   *You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop!
   *Don't employ "analysts". Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their "analysis" is worthless
   *If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do
   *Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis
   *Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how Analysis Paralysis really happens. 

The PDCA Model

   * Plan
   * Do
   * Check
   * Act

Causes

• Pride
• Narrow Mindedness
• The lure of infinite composability and decomposability
• Insistence on completing all analysis before beginning design.
• Regular change of leads and their philosophies (each trashing and restarting the work of the previous)
• Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work
• Lack of goals
• Increasingly conflicting goals (often political)
• Creative speculation, when discovery and definition are required.
• BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.
• Risk avoidance, fear of making a mistake.

References

[1] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern