"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).
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.
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++.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006