Friday, June 10, 2011

Is Experience Valuable?

I viewed a couple of the presentations from the Agile Connect 2011 event this week. One of my interests is software estimation and the challenge of estimating accurately so I really enjoyed the Deception and Estimation: How We Fool Ourselves presentation.

A couple of key points:
We deceive ourselves in all our daily estimates and we're hardwired to deceive

Deception is rampant in our daily lives and even encouraged For example, we instruct our children to feign respect for their elders, to write thank you notes for disappointing presents and to refrain from telling grandma that her breath stinks

What was most interesting to me was the article that was referenced in the presentation - The Experience Trap - where the main element of estimating, experience, was shown to be ineffective when dealing with complexity.

A key paragraph from the article:
When anyone makes a decision, he or she draws on a pre-existing stock of knowledge called a mental model. It consists largely of assumptions about cause-and-effect relationships in the environment. As people observe what happens as a result of their decisions, they learn new facts and make new discoveries about environmental relationships. Discoveries that people feel can be generalized to other situations are fed back, or “appropriated”, into their mental models. On the face of it, the process seems quite scientific — people form a hypothesis about a relationship between a cause and an effect, act accordingly, and then interpret the results from their actions to confirm or revise the hypothesis. The problem is that the approach seems to be effective only in relatively simple environments, where cause-and-effect relationships are straightforward and easily discovered. In more complex environments, such as software projects, the learning cycle frequently breaks down.


So, cause-and-effect and mental models don't work well in complicated environments like software projects but, because humans are not good at dealing with complexity, we tend to use software to help with complex situations.

I've often wondered about how software project failures would be different if we spent less time on estimating and more time on actual problem solving.

No comments: