Analysis Paralysis and Tunnel Vision

• By Matt Stephens
• July 18, 2005

Analysis paralysis is a term used to describe the state that a team lapses into when their analysis effort just doesn't progress because they're stuck creating overly precise UML diagrams, and arguing repeatedly over whether to use "includes" or "extends" on their use case diagrams. In some ways it could be seen as the opposite to the desired flow state.

It's really noticeable that teams who slip into analysis paralysis are often deeply anxious. Obviously there's the stress when they realize that they haven't made any progress for several months, but that's different. The anxiety begins earlier, when they boldly adopt an unfamiliar methodology on a new project.

Anxiousness is commonly associated with tunnel vision, in which a person gets too entrenched in one particular approach, and forgets to stand back and look at the bigger picture, to look for better alternatives. In his book Emotional Design, Donald Norman provides a nice example. If someone in an auditorium shouts "Fire!," the stampeding herd might be faced with an Exit door that happens to open inward. The visceral response in such situations is to try to push the door outward, in the direction of their escape; and if the door doesn't budge, to push harder. All higher-level reasoning has gone out the window (which the crowd would also consider if they weren't stricken with tunnel vision at that moment).

Slightly less dramatically, people also encounter tunnel vision in their reasoning process when they are faced with a task which exceeds their current level of ability. They become anxious, and their problem-solving ability narrows in scope so that all they can do is focus on the single, linear path that happens to be right in front of them. Lateral thinking? Wossat then?

So, what does this have to do with analysis paralysis? I have this theory that developers who encounter analysis paralysis do so because they've got tunnel vision. They're following a methodology because they desperately want to do the right thing. And because they want to do the right thing, they take every step in the methodology literally. They don't think about alternatives, the most important alternative being choosing not to do a particular prescribed step.

They get into this state for the same reason why they opted to follow a methodology in the first place: because they don't, strictly speaking, know how to proceed. Their hope is that the methodology will tell them how to get from A to B (or more precisely, how to get from the initial vague notion that "we need to write some software" to working source code that fulfils some specific business needs).

Essentially, the team members who have just adopted a new methodology are learning as they go along. In other words, the developers are faced with a task which (for the time being at least) is greater than the sum of their abilities. So they become anxious, possibly without realizing it. They're afraid to experiment or tailor the process. The natural outcome is that they develop tunnel vision, meaning that their higher-level reasoning abilities become very restricted, leaving them in a visceral state just barely able to follow the prescribed steps of their chosen methodology. So let's hope it's a good one, for their sakes!

Analysis paralysis is a core topic in my upcoming book Use Case Driven Object Modeling with UML: Theory and Practice (co-authored with Doug Rosenberg). (Actually it's not due to be published for a while so don't rush out looking for it just yet!)