Flylib.com

Books Software

 
 
 

The Value of Real Customers


The Value of Real Customers

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.



Customer Tests

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 served us well, but not perfectly . They were pretty easy to write, but because they didnt give us good debugging information, we would sometimes skip them when we shouldnt have. So the customer test suite is not as strong as it should be. Of course, if we had a true independent customer, they would be focused on making those tests strong to be sure that the product was working as they wanted. If the customer tests had been stronger, they would have turned up more problems. Had they turned up more problems, we would have had the incentive to improve our ability to get useful information out of them.

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 encountered a few cases where the tests ran but the GUI did not. We improved the tests in response to most of those, but my suspicion is that the tests are still a bit weak in some undiscovered areas. End to end is always further than we think it is.



Pair Programming

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 pairing with someone whom I havent worked with before makes the code better, and interestingly enough it makes the book better, too. Because I have talked through the design with my pair, Im a bit better prepared to detail it to you and Im far less likely to skip over important aspects.

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.