Chet and I tried hard to wear two hats, the customer hat and the programmer hat. We tried to demand the features that customers would want and to focus as programmers on quality code and on estimating the costs of things. We tried not to make programmer decisions on business topics. Since this is a book about how to learn while producing useful features, I think it worked fairly well. The presence of real customer input would quite likely have changed things, however. I can think of these possibilities:
Real customers would probably have had somewhat different priorities than we imagined. This might have changed the direction of the project in some ways. I think the resulting program, given the same amount of work, might have been better suited to immediate use, because our customers would be trying to use it.
Real customer tests would have helped. I feel sure that we tolerated a cryptic and incomplete testing language, in part because we knew the code and had confidence in it, so we did not feel the need for more, better, or easier customer tests. (In many cases, we were wrong to feel that confident. Programmers are like that.) An independent customer would probably have demanded more tests and different tests. In turn , this would very likely have caused us to recognize problems more easily and to fix them sooner.
Frankly, I am surprised, given that I planned this book and think of it as a book about programming, at how much value an independent customer could have provided. The lesson for you is that contact with real users, or someone who can stand in for real users, is of very great value on your projects as well. Once you have had a good XP customer, youll never want to be without them.