Ming the Mechanic:
Waterfalls and Chaos
The NewsLog of Flemming Funch
 Waterfalls and Chaos2007-06-19 22:22
5 comments
by Flemming Funch

Johnnie Moore used it as a couple of his slides at Reboot, and described it further in an old blog post, based on a paper on wicked problems. We're talking about how things are supposed to happen in somebody's neat mental model versus how it actually happens.
The authors put up this diagram. It shows the traditional view of a problem solving process. This should be pretty familiar to any kind of consultant. It shows four stages of problem solving: gather data, analyze data, formulate solution, implement solution. Apparently, this is called the waterfall model of problem-solving, where we move graciously from the area of looking at the problem to that of working out the answer.



A study at the Microelectronics and Computer Technology Corporation (MCC) looked at whether this model is a good description of what happens in the real world. So they took a team of successful designers and set them to work on a real world problem (designing an elevator control system). They then looked at how one designer actually spent his time. That's then plotted over our waterfall here:



That's interesting isn't it? He's clearly not following the script. Instead, he's jumping to a potential solution and then realising another aspect of the problem and so on. Here's someone who allegedly is a good designer and he's not doing "the right thing".
And they go ahead and try it with more different people, who don't fit the neat waterfall model either, and who don't at all match each other's patterns either. And we were talking about skilled, successful designers there.

The conclusion is of course along the lines of realizing that in the real world real people do something very different from what they're supposed to according to neat diagrams. They probably couldn't do it exactly like the diagram, or if they did, they would be very ineffective. Seen from the perspective of the people who like neat diagrams, the actual behavior seems chaotic. But it is productive chaos, and not really chaos. It is a different kind of order.

It is often not wise to try to impose rigid one or two-dimensional patterns on problems and solutions and people and organizations that really have many more dimensions to them. You can simplify things that are complicated, but over-simplifying functioning complexity is unwise.


[< Back] [Ming the Mechanic]

Category:  

5 comments

20 Jun 2007 @ 04:35 by Jeff Conklin @69.107.121.29 : New link for waterfall paper
Hi Fleming. If you go back to the paper by Raymonde Guindon in HCI you can view the original "chaos" graphs, based on the empirical data. (The graph in my paper is a bit idealized to simplify the story line.) I view the jagged line as a depiction of learning, as opposed to the waterfall's depiction of "already knowing". It helps to drive home the "symmetry of ignorance" that Horst Rittel talked about in his wicked problem papers.

By the way, there's a much cleaner and updated version of the wicked problem paper (but still with the same graphs) at http://www.cognexus.org/wpf/wickedproblems.pdf .

Cheers,
Jeff Conklin  

20 Jun 2007 @ 15:30 by Quirkeboy @209.92.185.200 : What if...
.. you consider a set of rules like this:
1. Gather data, analyze data, formulate solution, implement solution.
2. If you screw up any of the above.. go back and do it again.

I think that the waterfall model works fine.. but in the real world errors are made which causes the spikes. If ALL available data was collected.. and all aspects were considered.. and the solution was based on sound theory.. and it was implemented correctly.. you wouldnt see these spikes.

The waterfall model is successful as a definition of coming to a solution flawlessly. This success is also illustrated when you look at it with what deviations you DONT see. You dont see anybody STARTING at the implementation stage... or ENDING in the analyze data stage. If you begin with implementation.. it WASNT a problem to begin with! You may find people STARTING with "Formulate Solution" but I would argue that collection of data still preceded it. The person was merely basing his decisions based on information collected prior to the problem.

The flaw in the waterfall model comes about when you assume that people dont screw up. And even extremely talented designers will find it nearly IMPOSSIBLE to collect ALL data.. account for all variations.. to examine it from EVERY possible angle. Pirsig said that the more you look at a phenomena the more hypothesis you will find to explain it.. and never find the end.

So perhaps the only flaw in the "waterfall model" is not accounting for human flaw?  

20 Jun 2007 @ 23:32 by ming : Wicked problems
Thanks Jeff. I'll look it over in more detail. Well, I sometimes prefer the simplified version, the one that makes the point clear. But experimental data isn't necessarily so clear.  

20 Jun 2007 @ 23:40 by ming : Ideal models
Quirkeboy, it is also that the things one does will create a feedback loop. Your results from doing something will produce new data. Like, I recognize all this from software development, for example. Traditional software life-cycle models would be somewhat like the waterfall model there. Somebody would gather together the requirements and write a report about it. Somebody would analyze it, look at alternative solutions, and write the specs for the best way of doing it. Somebody else would come along and implement the specs into a solution. Then somebody would test it. Etc. Except for that loads of things only become known during the process. Problems or new information might appear while it is being implemented. And if you then need to go back and re-do those big steps - that's very expensive and time consuming. That's why more modern software development techniques (pragmatic programming, extreme programming, etc) pretty much start with the implementation right away. So, a more active model where all the stake holders are working together, and where the feedback loop is preferably daily, rather than 6 months later.

As to the above model, one could maybe say that Gathering Data, Analyzing Data, Formulating Solutions and Implementing Solutions are all things that need to happen. But that it would be unrealistic to expect them to happen one after the other. One can prototype possible solutions early on, and use the feedback from that to gather better data, etc.  

21 Apr 2016 @ 19:28 by Kiana @188.143.232.32 : VDNyQMrtev
Times are chnnigag for the better if I can get this online!  

Other stories in
2010-07-10 13:01: Strong Elastic Links
2010-07-08 02:27: Truth: superconductivity for scalable networks
2010-06-27 02:28: Be afraid, be very afraid
2008-07-06 23:20: Laws of social networks
2008-06-20 15:40: Peer material production
2008-05-06 13:57: Why can't we stick to our goals?
2008-02-21 21:16: Open social networks
2007-11-08 01:49: The value of connections
2007-11-07 00:51: Diversity counterproductive to social capital?
2007-07-13 23:42: Plan vs Reality


[< Back] [Ming the Mechanic] [PermaLink]? 


Link to this article as: http://ming.tv/flemming2.php/__show_article/_a000010-001860.htm
Main Page: ming.tv