Another great TED talk to watch – Jill Bolte Taylor’s Stroke of Insight

What a great way to start off a St. Patrick’s Day. This is certainly worth 20 minutes of your life. As someone inclined to spend entirely too much of my time inside the left-hemisphere of my brain, I found this especially affecting.  

Stroke of insight: Jill Bolte Taylor on TED.com

Neuroanatomist Jill Bolte Taylor had an opportunity few brain scientists would wish for: One morning, she realized she was having a massive stroke. As it happened — as she felt her brain functions slip away one by one, speech, movement, understanding — she studied and remembered every moment. This is a powerful story of recovery and awareness — of how our brains define us and connect us to the world and to one another. (Recorded February 2008 in Monterey, California. Duration: 18:44.)

Watch Jill Bolte Taylor’s talk on TED.com, where you can download it, rate it, comment on it and find other talks and performances.

Read more about Jill Bolte Taylor on TED.com.

NEW: Read the transcript >>

Zen and the scientific method

Espen reminded me of the following passage from Zen and the Art of Motorcycle Maintenance. It is a wonderfully succinct description of the scientific method and its power to protect us from the risks of wishful thinking when problems call for discipline. We used to use this passage as a piece of our basic training for all incoming consultants at Diamond.

 

…this morning I talked about hierarchies of thought–the system. Now I want to talk about methods of finding one’s way through these hierarchies–logic.

Two kinds of logic are used, inductive and deductive. Inductive inferences start with observations of the machine and arrive at general conclusions. For example, if the cycle goes over a bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over a long smooth stretch of road and there is no misfiring, then it goes over a fourth bump and the engine misfires again, you can logically conclude that the misfiring is caused by the bumps. That is induction: reasoning from particular experiences to general truths.

Deductive inferences do the reverse. They start with general knowledge and predict a specific observation. For example, if from reading the hierarchy of facts about the machine, the mechanic knows the horn of the cycle is powered exclusively from the battery, then he can logically infer that if the battery is dead, the horn will not work. That is deduction. Solution of problems too complicated for common sense to solve is achieved by long strings of mixed inductive and deductive inferences that weave back and forth between the observed machine and the mental hierarchy of the machine found in the manuals. The correct program for this interweaving is formalized as scientific method.

Actually I have never seen a cycle-type maintenance problem complex enough to really require full-scale formal scientific method. Repair problems are not that hard. When I think of formal scientific method, an image sometimes comes to mind of an enormous juggernaut. A huge bulldozer–slow, tedious, lumbering, laborious, but invincible. It takes twice as long, five times as long, maybe a dozen times as long as informal mechanic’s techniques, but you know in the end you are going to get it. There is no fault isolation problem in motorcycle maintenance that can stand up to it. When you’ve hit a really tough one, tried everything, racked your brains and nothing works, and you know that Nature this time has really decided to be difficult, you say, “Okay, Nature, that’s the end of the nice guy,” and you crank up the formal scientific method.

For this you keep a lab notebook. Everything gets written down, formally, so you know at all times where you are, where you’ve been, where you’re going and where you want to get. In scientific work and electronics technology this is necessary because otherwise the problems get so complicated you get lost in them and confused and forget what you know and what you don’t know and have to give up. In cycle maintenance, things are not that involved, but when confusion starts, it’s a good idea to hold it down by making everything formal and exact. Sometimes just the act of writing down the problem straightens out your head as to what they really are.

The logical statements written down into the notebook are broken down into six categories: (1) statement of the problem, (2) hypothesis as to the cause of the problem, (3) experiments designed to test each hypothesis, (4) predicted results of the experiments, (5) observed results of the experiments and (6) conclusions from the results of the experiments. This is no different from the formal arrangement of many college and high school lab notebooks. But the purpose here is no longer just busywork. The purpose is precise guidance of thought that will fail if they are not accurate.

The real purpose of the scientific method is to make sure Nature hasn’t misled you into thinking you know something you don’t actually know. There is not a mechanic or scientist or technician alive who hasn’t suffered from that one so much that he’s not instinctively on guard. That’s the main reason why so much scientific and mechanical information sounds so dull and so cautious. If you get careless or go romanticizing scientific information, giving it a flourish here and there, Nature will soon make a complete fool out of you. It does it often enough anyway even when you don’t give it opportunities. One must be extremely careful and rigidly logical when dealing with Nature: one logical slip and an entire scientific edifice comes tumbling down. One false deduction about the machine and you can get hung up indefinitely.

In Part One of formal scientific method , which is the statement of the problem, the main skill is in stating no more than you positively know. It is much better to enter a statement “Solve Problem: Why doesn’t cycle work?” which sounds dumb, but is correct, than it is to enter a statement “Solve Problem: what is wrong with the electric system?” when you don’t absolutely know the trouble is in the electric system. What you should state is “Solve Problem: What is wrong with the cycle?” and then state as the first entry in Part Two: “Hypothesis Number One: The trouble is in the electrical system.” You think of as many hypothesis as you can, then you design experiments to test them to see which are true and which are false.

This careful approach to the beginning questions keeps you from taking a wrong turn which might cause you weeks of extra work or can even hang you up completely. Scientific questions often have a surface appearance of dumbness for this reason. They are asked in order to prevent dumb mistakes later on.

Part Three, that part of formal scientific method called experimentation, is sometimes thought of by romantics as all of science itself because that’s the only part with much visual surface. They see lots of tubes and bizarre equipment and people running around making discoveries. They do not see the experiment as part of a larger intellectual process and so they often confuse experiments with demonstrations, which look the same. A man conducting a gee-whiz science show with fifty thousand dollars’ worth of Frankenstein equipment is not doing anything scientific if he knows beforehand what the results of his effort are going to be. A motorcycle mechanic, on the other hand, who honks the horn to see if the battery works is informally conducting a true scientific experiment. He is testing a hypothesis by putting the question to Nature. The T.V. scientist who mutters sadly “the experiment is a failure; we have failed to achieve what we had hoped for,” is suffering mainly from a bad script writer. An experiment is never a failure solely because it fails to achieve predicted results. An experiment is a failure only when it also fails adequately to test the hypothesis in question, when the data it produces don’t prove anything one way or another.

Skill at this point consists of using experiments that test only the hypothesis in question, nothing less, nothing more. If the horn honks, and the mechanic concludes the whole electrical system is working, he is in deep trouble. He has reached an illogical conclusion. The honking horn only tells him that the battery and horn are working. To design an experiment properly he has to think very rigidly in terms of what directly causes what. This you know from the hierarchy. The horn doesn’t make the cycle go. Neither does the battery, except in a very indirect way. The point at which the electrical system directly causes the engine to fire is at the spark plugs, and if you don’t test here, at the output of the electrical system, you will never really know whether the failure is electrical or not.

To test properly the mechanic removes the plug and lays it against the engine so the base around the plug is electrically grounded, kicks the starter lever and watches the spark-plug gap for a blue spark. If there isn’t any he can conclude one of two things: (A) there is an electrical failure or, (B) his experiment is sloppy. If he is experienced, he will try it a few more times, checking connections, trying every way he can think of to get that plug to fire. Then, if he can’t get it to fire, he finally concludes that A is correct, there is an electrical failure, and the experiment is over. He has proved that his hypothesis is correct.

In the final category, Conclusions, skill comes in stating no more than the experiment has proved. It hasn’t proved that when he fixes the electrical system the motorcycle will start. there may be other things wrong. But he does know that the motorcycle isn’t going to run until the electrical system is working and he sets up the next formal question: “Solve Problem: what is wrong with the electrical system?”

He then sets up hypotheses for these and tests them. By asking the right questions and choosing the right tests and drawing the right conclusions the mechanic works his way down the echelons of the motorcycle hierarchy until he has found the exact specific cause or causes of the engine failure, and then he changes them so that they no longer cause the failure.

An untrained observer will see only physical labor and often get the idea that physical labor is mainly what the mechanic does. Actually the physical labor is the smallest and easiest part of what the mechanic does. By far the greatest part of his work is careful observation and precise thinking. That is why mechanics sometimes seem taciturn and withdrawn when performing tests. They don’t like it when you talk to them because they are concentrating on mental images, hierarchies, and not really looking at you or the physical motorcycle at all. They are using the experiment as part of a program to expand their hierarchy of knowledge of the faulty motorcycle and compare it to the correct hierarchy in their mind. They are looking at underlying form.

(Chapter 9. pages 107-111 from Pirsig, R. M. (1999). Zen and the art of motorcycle maintenance. 25th Anniversary Edition. Morrow.)

Tags:

Learning to balance theory and evidence

I finally got around to taking a peek at this video of Clay Shirky’s presentation at the Supernova 2007 conference in June. It’s relatively short and Shirky is a good speaker. Like Jimmy Guterman, I was particularly taken with Shirky’s observation on AT&T’s reaction to a particular proposal: “They didn’t care that they’d seen it work in practice because they already knew it wouldn’t work in theory.”

How often do you see a theory blind believers to facts? Do you sense that the problem is becoming worse? The relationship between theory and evidence can be quite complex and failing to appreciate those complexities usually spells trouble. My own bias is toward the underlying methods and philosophy of modern science. You always have to be prepared for the ugly facts to kill your beautiful theories (thank you Thomas Huxley).

Clay Shirky, a Shinto Shrine, and the Sentence of the Year

By Jimmy Guterman

If, like me, you were unable to attend Supernova this year and you’re still kicking yourself, you can stop now. Conference organizer (and former Release 1.0 editor) Kevin Werbach has begun posting videos of the proceedings. I’ve only seen one so far, a dizzying presentation by Clay Shirky in which he likens the guardians of a Shinto shrine to the perl community…

Solving puzzles or framing mysteries. Dealing with wicked problems

There’s in interesting essay in the most recent issue of Smithsonian Magazine on the importance of understanding whether you are working on a puzzle or a mystery written by Gregory Treverton, who is the Director of RAND’s Center for Global Risk and Security.

There’s a reason millions of people try to solve crossword puzzles each day. Amid the well-ordered combat between a puzzler’s mind and the blank boxes waiting to be filled, there is satisfaction along with frustration. Even when you can’t find the right answer, you know it exists. Puzzles can be solved; they have answers.

But a mystery offers no such comfort. It poses a question that has no definitive answer because the answer is contingent; it depends on a future interaction of many factors, known and unknown. A mystery cannot be answered; it can only be framed, by identifying the critical factors and applying some sense of how they have interacted in the past and might interact in the future. A mystery is an attempt to define ambiguities.

Puzzles may be more satisfying, but the world increasingly offers us mysteries. Treating them as puzzles is like trying to solve the unsolvable—an impossible challenge. But approaching them as mysteries may make us more comfortable with the uncertainties of our age. [Risks and Riddles.]

Treverton’s essay focuses on the distinction in the context terrorism and law enforcement, but it is worth pondering more broadly. Most of our training and experience in organizations is focused on puzzle-solving skills. MBA programs focus on equipping their graduates with toolkits for solving a host of problems; once those problems have been appropriately identified and bounded. They offer far less guidance on the far more difficult task of framing issues in ways that can be addressed.

Absent good practices in framing issues, the temptation is always to force issues into puzzle structures that can be solved. Treverton offers an important reminder of the risks of forcing mysteries into puzzles.

Another helpful language system to employ here is Horst Rittel’s notion of “wicked problems.” Jeff Conklin, at the CogNexus Institute has some excellent materials to help get started down this path. Take a look at “Wicked Problems and Social Complexity” (PDF file) and “Issues as Elements of Information Systems” (PDF file) which is Rittel’s original paper on the topic. Conklin has also written an excellent book on the topic: Dialogue Mapping : Building Shared Understanding of Wicked Problems. Finally, there is an open source software tool, Compendium, available to support some of the techniques for framing and working on wicked problems that Conklin advocates.

Rich collection of idea generation methods

While I wouldn't be so bold as to label it a “definitive collection,”
it is nonetheless very rich. The techniques I am familiar with are very
effective and effectively described, which gives me confidence that
those new to me are worth investigating as well.

The definitive collection of idea generation methods. Martin Leith gifts us with a page full of idea generation methods, a treasure trove for facilitators and team leaders. The definitive collection of idea generation methods

“This website lists and
explains every idea generation method I've encountered during the past
15 years. It is the result of extensive research; my many sources
include books, management journals, websites, academics, consultants
and colleagues.

The methods have been drawn not just from the worlds of creative
problem solving and innovation, but also from other worlds such as
organisational change, strategic planning, psychotherapy, the new
sciences and the creative arts.

The methods are listed below. Each is linked to a description, and
in some cases you will find full instructions for using the method to
generate ideas.”

Thanks, Martin!

[via eLearningpost]

,

By noemail@noemail.org (Nancy White). [Full Circle Online Interaction Blog]

Places to Intervene in a System

A nice reminder from Jack Vinson about an excellent resource on ways to
poke on complex systems that are more likely to be effective than our
typical efforts. I’ve pointed to this before in several incarnations (here and here).
We’ve certainly seen more than our share recently of ineffective ways
to intervene. Perhaps we can hope that some of these lessons will find
their way into broader practice.

A 1997 article by Donella Meadows has been reprinted in a software developer magazine, Places to Intervene in a System. (Here’s a fuller version from 1998.)

Folks who do systems analysis have a great belief in “leverage
points.” These are places within a complex system (a corporation, an
economy, a living body, a city, an ecosystem) where a small shift in
one thing can produce big changes in everything.

The systems community has a lot of lore about leverage points. Those
of us who were trained by the great Jay Forrester at MIT have absorbed
one of his favorite stories. “People know intuitively where leverage
points are. Time after time I’ve done an analysis of a company, and
I’ve figured out a leverage point. Then I’ve gone to the company and
discovered that everyone is pushing it in the wrong direction!”

[via Johanna Rothman]

jackvinson (jackvinson@jackvinson.com) [Knowledge Jolt with Jack]

Frankston on DRM, markets, and why intelligent design isn't

Bob Frankston has had several recent posts illuminating the long-term
strategic blindness of competitors pursuing doomed approaches to
Digital Restrictions Management (DRM). The short and sweet version:

DRM vs the Bathroom.
For those who found my recent DRM post too complicated I’ll put it more
simply. There are those who believe that I must not zap commercials
while watching their content. It's not very different from saying I’m
not allowed to go to the bathroom during commercials — I must use a
DRM compliant toilet in order to implement such policies.

If they can require that all my wires and devices be DRM complaint why
not the other distractions that reduce the value of their content? [SATN]

In a much longer post,
well worth your attention, Frankston draws some very provocative
connections between DRM approaches to competition and the fundamental
emptiness of intelligent design as a way to not think about how
evolutionary processes truly work. Several key grafs:

Too bad evolution is taught in biology class because it makes it hard to see the larger issues. Dynamic systems are evolutionary systems and if you
try to limit their dynamics they fail. If you believe in intelligent
design you can assume that systems can be guided. Marketplaces are just
complex systems. If you give the incumbents the role of the intelligent
designer the systems will fail because you don’t allow for new ideas.
….

This is why I keep emphasizing that teaching evolution in biology classes
leaves us without understanding that evolution is a characteristic of
all systems not just “special” ones. Without such understanding it is
difficult to see how and why the Internet works. Even more to the point
why it works despite and not because of governance. Why complexity is
an emergent property of the lack of understanding. We don’t “solve”
complexity by layering on top of it. When we design systems we have to
go underneath the system expose the simplicity.

It’s not at all fair to accuse those who thwart marketplace processes as being “anti-evolutionists”. Even though I think it is obvious the onus is
still on me to demonstrate that the mechanisms are the same. I still
claim that there is a basic philosophical alignment akin to the one
that George Lakoff posits in Moral Politics.
It is hard to trust the marketplace because at any point in time it’s too easy to see the “right” answer. It’s even more difficult to see the
importance of these dynamic processes when cling to the present for
safety.[SATN]

Hierarchical organizations are typically not very comfortable
with real market dynamics. Most strategy work is about finding ways to
avoid or interfere with the smooth workings of competitive markets
without going to jail. At root, what Frankston is arguing is that in
the long run, markets will always win.

Bertrand Russell on problems and solutions

An interesting reminder for the morning. It is curious that we
generally devote so little time to this in both our education and our
work practices. Think how often the organizational and educational
systems we are embedded in convey the implicit assumption that someone
else has already defined the problem correctly and that our only
responsibility is to produce the relevant solution. Possibly an
acceptable message in an industrial world, but not one I would
encourage in today's world

On Problems. On Problems

“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.”
— Bertrand Russell (1872 – 1970)

Alan Kay on programming language design

Always worth seeing what Kay has to say. The slashdot thread has its moments as well.

How Heraclitus would Design a Programming Language. CowboyRobot writes “Developer of Smalltalk Alan Kay has an interview on ACM Queue
where he describes the history of computing and his approach to
designing languages. Kay has an impressive resume (PARC, ARPAnet,
Atari, Apple, Alan Turing Award winner) and has an endless supply of
memorable quotes: 'Perl is another example of filling a tiny,
short-term need, and then being a real problem in the longer term,'
'Once you have something that grows faster than education grows, you’re
always going to get a pop culture,' 'most undergraduate degrees in
computer science these days are basically Java vocational training,'
'All creativity is an extended form of a joke,' and 'nobody really
knows how to design a good language.'” [Slashdot:]

A Swiss Army Knife Approach to Project Management

I’m running a bit behind these days. That makes it a bit ironic that my
most recent column at Enterprise System Journal looks at the topic of
project management.

The column actually appeared last week and looks at project management
from a minimalist perspective. Jim Powell, my editor there, decided to
title it A Swiss Army Knife for Project Management.
My launching point was to ask what everyone needed to know about
project management rather than what the specialists needed to know.

My thinking on this topic has certainly benefitted from the excellent Focused Performance Blog by Frank Patrick and Hal Macomber’s Reforming Project Management.
I’ve also begun to take a close look at basecamp and at ubergroups as
toolsets that are trying to simplify project management for all of us
in place of supporting the complexities that only a small handful of
experts actually need.