Preventing Analysis Paralysis

from Source Making.com 8/14 enhanced by Peter/CXO Wiz4biz

Background: Analysis Paralysis is one of the classic Anti-Patterns in hardware & software development. Object-oriented analysis is focused on decomposing a problem into its constituent parts, but there is no obvious method for identifying the exact level of detail necessary for system design. Frequently, the focus is shifted from decomposing to a level where the problem can be easily understood by the designers to applying the techniques to achieve the mythical “completeness.” Also, system developers often willingly fall prey to Analysis Paralysis, as “designs never fail, only implementations.” By prolonging the analysis & design phases (procrastination), they avoid risking accountability for results. Of course, this is a losing strategy, because usually there is some point after which a working implementation is expected.

General Form. Analysis Paralysis occurs when the goal is to achieve perfection and completeness of the analysis phase. This AntiPattern is characterized by turnover, revision of the models, and the generation of detailed models that are less than useful to downstream processes. Many developers new to object-oriented methods do too much up-front analysis & design. Sometimes, they use analysis modeling as an exercise to feel comfortable in the problem domain. One of the benefits of object-oriented methods is developing analysis models with the participation of domain experts. Otherwise, it’s easy to get bogged down in the analysis process when the goal is to create a comprehensive model.

Assumptions of Analysis Paralysis. Detailed analysis can be successfully completed prior to coding.
· Everything about the problem is known by deduction.
· The analysis models will not be extended nor revisited during development. Object-oriented development is poorly matched to deductive analysis, design, & implementation processes. Effective object-oriented development is an incremental process during which incremental & iterative results of analysis are validated through design & implementation and used as feedback into later system analysis.

A key indicator of Analysis Paralysis is that the analysis documents no longer make sense to the domain experts.

Symptoms & Consequences
· There are multiple project restarts and much model rework, due to personnel changes or changes in project direction.
· Design and implementation issues are continually reintroduced in the analysis phase.
· Cost of analysis exceeds expectation without a predictable end point.
· The analysis phase no longer involves user interaction. Much of the analysis performed is speculative.
· The complexity of the analysis models results in intricate implementations, making the system difficult to develop, document, and test.
· Design and implementation decisions such as those used in the Gang of Four design patterns are made in the analysis phase.

[ Typical Causes, Refactored Solution, Increments. Continue? Minimal Analysis, At the Architectural level, in Premium Content ]