Driving Metaphor

My mother taught me how to drive when I was about 12. We were on I-5 near Chico, a straight, boring stretch of really wide highway. She let me feel how the steering wheel was connected to the direction of the car, then told me to get the car straight in our lane. I carefully lined the car up. Then my mind wandered a little. I was snapped back to attention when we hit the gravel (will I have the guts to let my kids do this when the time comes?)

"Driving is not about getting the car pointed in the right direction." I was ready to listen now. "Driving is about constant adjustment. A little this way, a little that way, forever. You always pay attention. You are always prepared to change things."

This describes ExtremeProgramming's philosophy to me. The "right direction" for the project is irrelevant. What matters is that you pay attention, and that you are constantly adjusting. If you do this, there is no externally visible difference between the two.

I told my wife this story. "What a guy thing. An endless stream of problems to be solved. Heaven. Driving is about flow. If you make the adjustments small enough and quick enough, then they completely disappear." So, to balance the above story, check out OneHandOnTheYoke (aka power steering).

--KentBeck

You should listen to your wife more. This DrivingMetaphor seems to be very dominant control oriented. As if someone is controlling the machinery. In KentsTalkAtXpImmersionTwo you suggested the XP paradigm was a Conversation. Check out ConversationMetaphor and see how it fits.

Ron, could you fill in the NoBadNews story? I think it shows one of the reasons WhyIsXpSoHard. The driving paradigm is at odds with the car pointing paradigm prevailing in much of the corporate world.

SteerWithYourEyes

Look at the two versions of the event in terms of granularity. He and she both saw incremental controls, it's just a matter of degree. Are a series of minor adjustments more control oriented than apparent continuous domination?

"Writing a novel is like driving a car at night. You can only see as far as your headlights, but you can make the entire journey that way." --E. L. Doctorow

Hmmm. I'm not sure that I can express this as concisely as I'd like, but I'll try.

Many tasks cannot be performed adequately by someone who finds it necessary to *think* about the low-level sub-tasks which must be performed in order to successfully complete the main task. Whether we are talking about coding, driving, sport, or any other intellectual or physical activity, if you are having to think about syntax, how to keep the car pointing the right way, how to balance the boat (rowing was my sport), then you will not simultaneously be able to see the "BigPicture".

In order to perform a task *really well*, you must be continually aware of the BigPicture, and actually performing the task subconsciously in response to what you perceive is incomplete or wrong in the BigPicture. This usually requires that you have first spent a significant amount of time building up the level of task which you are able to perform in this way (and getting lots of things horribly wrong in the process). Progress is often easier if someone else (a "Master") is available to help you see the BigPicture while you are working on the little ones.

When you see this, you will understand why so many people write bad C++.

EditText of this page (last edited September 16, 2004)
FindPage by browsing or searching

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006