No fixed direction remains valid for long; whether we are talking about the details of software development, the requirements of the system, or the architecture of the system. Directions set in advance of experience have an especially short half-life. Change is inevitable, but change creates the need for feedback.
I remember an all-day presentation I gave in Aarhus, Denmark. One front-row attendee's face got cloudier and cloudier as the day progressed. Finally he couldn't stand it. "Wouldn't it be easier just to do it right in the first place?" Of course it would, except for three things:
We may not know how to do it "right". If we are solving a novel problem there may be several solutions that might work or there may be no clear solution at all.
What's right for today may be wrong for tomorrow. Changes outside our control or ability to predict can easily invalidate yesterday's decisions.
Doing everything "right" today might take so long that changing circumstances tomorrow invalidate today's solution before it is even finished.
Being satisfied with improvement rather than expecting instant perfection, we use feedback to get closer and closer to our goals. Feedback comes in many forms:
Opinions about an idea, yours or your teammates'
How the code looks when you implement the idea
Whether the tests were easy to write
Whether the tests run
How the idea works once it has been deployed
XP teams strive to generate as much feedback as they can handle as quickly as possible. They try to shorten the feedback cycle to minutes or hours instead of weeks or months. The sooner you know, the sooner you can adapt.
It is possible to get too much feedback. If the team is ignoring important feedback; it needs to slow down, frustrating as that may be, until it can respond to the feedback. Then the team can address the underlying issues that caused the excess of feedback. For example, suppose you move to quarterly releases and suddenly have more defect reports than you can respond to before the next quarter's release. Slow down releases until you can handle the defect reports and still develop new functionality. Take the time to figure out why you are creating so many defects or why each defect takes so long to address. Once you've solved the basic problem; you can start releasing quarterly again, cranking up the feedback machine.
Feedback is a critical part of communication. "Is performance going to be a problem?" "I don't know. Let's write a little performance prototype and see." Feedback also contributes to simplicity. Which of three solutions will turn out to be simplest? Try all three and see. While implementing the same thing three times may seem wasteful, it may be the most efficient way to arrive at a solution whose simplicity you can live with. At the same time, the simpler the system, the easier it is to get feedback about it.