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
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
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.
Lets reflect further on the customer tests. I see these key lessons here:
First, the initial customer test was difficult to do. We didnt want to do it, we resisted it, and we had to get a bit creative to figure it out. Once we made the commitment to have the test, however, it took only a couple of hours to do it. This is almost always the way, in my experience. We think we dont need the test, we dont see how do to it, and then it isnt hard to do.
Second, the tests
Finally, as I learn anew on every project, end to end is further
than we think it is. The most effective customer tests test the
system from one edge to the other. In the case of the XML Notepad,
that means from keyboard to display. We
Its fascinating how much better pair
programming made the program and the book. This works for a number
of reasons, but the bottom line for me is pretty clear: I work
better with someone to collaborate with, and the closer the
collaboration, the better things seem to go. Even
Even bringing my pair up to datefreshening the pairs eyeshelps a lot. It makes me say out loud the things Ive been thinking. Often even I can hear how stupid something Im doing is. The bottom line that Id offer to you is to try pair programming until youre good at it, and then you can decide whether it helps you as much as it helps me. It just might.