Recently at church the Sunday School teacher asked, "does anyone have a story about what that means?" I have noticed a shift to the post-modern emphasis upon narrative over the old-fashioned emphasis upon doctrine. Thus I started thinking thru a thesis/antithesis with "story" at one end pole. What was the other pole? I figured "explanation." A generation ago, the teacher would ask the class for an "explanation" instead of a "story."
Story-driven methodologies appear at church and in software engineering. In both contexts relevant facts are brought to light in a narrative descrptive structure. In church people tell their stories or use stories to point to something deeper--an encounter with the divine or some insight into our nature. This approach has pushed aside doctrinal or dogmatic teaching.
Similarly, some software development teams have adopted a story-driven development model. The software engineer interacts with the customer to discover "stories" that guide the software development process. Each story is a Use Case of the system expressed in narrative form. A story provides a scenario of stimuli from users or external systems and responses by the software solution. The narrative provides a structure whereby phenomena can be elaborated upon and described in measureable, repeatable terms. The distinction between Story Driven Development and Use Cases is that UML is the domain of Big Up-Front Design whereas Story Driven Development is more incremental and iterative just as Test Driven Development is so.
Stories are good in software engineering because every software project is a learning exercize. It invariably starts at "the point of maximum ignorance" and proceeds from there. Similarly, religion today is characterized by more doubt than faith.
Stories are a strategy for coping with incomplete and imperfect knowledge. This seems apt during requirements discovery. At this point, the client is more likely to know less consciously than he knows unconsciously. When a conscious explanation is demanded from him, he may offer something spurious. Conversely, if he were to offer a narrative description, implicit and unconscious information is more likely to slip into the "story." (See Malcolm Gladwell's "Blink: The Power Of Unconscious Thinking." )
Story or testimony places only one demand, that of honesty. The reader has to trust the story reflects the phenomena as perceived by the story-teller. This approach is very post-modern. It arrogates to itself minimal demands of "truth" or of "how" the phenomena come to be.
Reductionism is a necessary survival trait in both religion and in software engineering. Nothing will turn a pleasant philosophical/theological chat ugly faster than the assertion of some point of dogma someone else in the room anathamatizes. And I cannot say how many times a productive engineering meeting has ground to a halt upon getting bogged down in the "hows" while the "what's" remain only partially known. Story-based approaches focus everyone on the "what." This focus lets us all describe and clarify these things most immediately pertinent while deferring the deeper parts to the experts.
Mention of the experts brings us to note that story-based techniques work best in mixed company: in the mixed multitude of believers and skeptics in the theological domain, or in the mix of customer and solution-provider in the software domain.
The Bible was written by and to pre-scientific people. A lot of trouble springs from ignoring this point. The current approach is to interpret it phenomenologically. If the Bible says "sunrise" or "sunset" it means the same thing the weatherman on television means. Neither is making a statement about astronomy, both are saying when the day starts or ends.
There are at least three models that describe the motion of celestial bodies. Ptolemy articulated a system of wheels within wheels with the Earth at the center of the universe and everything moving around it. Copernicus created a model with the Sun at the center of the universe with the earth moving around it. Meanwhile, the Babylonians had created a purely mathematical description that made no attempt to get to the underlying mechanisms underlying the observed phenomena.
In his 1974 Caltech commencement address Dr. Richard Feynman described the Cargo Cult of the south seas. He describes them with this: "During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they've arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head to headphones and bars of bamboo sticking out like antennas--he's the controller--and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land."
This shows a risk of the story-driven approach. The Cargo Cultists grasp phenomena, they know the story. We must not stop there. We understand why cargo planes came to remote islands and we understand why with the war over, they quit coming.
You have to think about the stories, put them together and underlying mechanisms that explain the phenomena. It is hard to go beyond phenomena we all agree about and add something to it. It paints a target on you. People will argue and your explanation will compete with others' explanations. A few centuries ago folks got burned at the stake when their explanations were shot down. As you may recall the competition between heliocentric and geocentric models gave rise to a lot of angry debate. Had it not been for Galileo's invention of the telescope, the debate might still be ongoing.
Feynman says that real science requires honesty. There will be parts of the story that don't fit your explanation. In fact, when Copernican astronomy specified circular instead of elliptical planetary orbits, its predictions fit the phenomena worse than Ptolemaic astronomy. Galileo's telescope added stories about Jupiter's moons. It's said that some refused to look through his telescope. No honest. Honestly dealing with the bits that don't fit replace some theories and correct other theories.
There is a certain arrogance in an "explanation" emphasis that's absent from "story" emphasis. "Explanation" presumes that one knows more than what's immediately apparent. "Story" acknowledges the limitations of perspective and scope. And it is much less likely to be contradicted by things like Copernican revolutions. On many software projects one learns that the underlying model formulated at one time is inadequate when you learn more later. Thus I think a "story" with its focus upon a sequence of immediate phenomena is less likely to prove wrong than an "explanation". Later stories will elaborate details latent in earlier stories, but not contradict them. (See Thomas Kuhn's "Structure of Scientific Revolution.")
Stories should feed theories. Theories inspire disagreement and argument. Debate may scrape the frothy bits off a theory, but the real advancement comes as more stories are incorporated into those theories. This iterative process is the synthesis of "story" and "explanation."
No comments:
Post a Comment