Subsequent Iterations and Releases

It s appropriate on every project to look ahead, and this one is no exception. We have just scratched the surface of what the customer might want. There will be the usual file operations: save, open , close, and so on. There will be edit operations like copy and paste, as well as lots of XML-oriented commands. We know that the customer will want to see the resulting Web page.

Like any other user , our customer has a long list of features he d like to have. We ll learn to estimate how hard they are, and using that plus a sense of value, our customer will decide what s best for the Web site and for this book. All those things might be useful. They re all the sort of thing you d find in a typical Marketing product plan. We think that some of these ideas might have value and some might not. As the project moves along, we ll keep you up to date on how our customer (one last time: that s us) thinks about investing in these features.

Tracking all the features of a complete product, even one as simple as the XML Notepad, would require a book much longer than this one. We ll limit ourselves here to enough stories to make the product seem real and to teach the lessons we want to offer.

Lesson: What Have We Learned So Far?

Even this early on, there are some lessons to call to your attention:

• Simple estimation. We did some simple estimation of the things our customer wanted. We suggested things to implement that should surely look like progress to our customer, while allowing us to focus on learning important and central things about how the app works. We steered away from fancy GUI stories that would look good but wouldn t focus on the real guts of the application.

• Collaborate with our customer. Now this was easy in our case, but the principles are the same. Make the customer aware of the cost of features and the risk associated with them. Then let them decide what we should work on.

• Focus on delivery. Even in our first iteration, we ll be delivering a customer story. We really don t know .NET or C# at this point. We could make a case that we need training and time to learn. And surely we ll go more slowly now than we will when we re more adept. But still, we focus each week s work on delivering something ”anything ”that the customer can see as progress.

• Balance ambition with reality. Everyone, when envisioning some new product idea, sees good things that will never happen. We just can t have everything ”as Chet asks, where would we keep it? As programmers who have to deliver this stuff, we want to balance our customer s enthusiasm , and our own, with some reality. We do that not by being pessimistic and pushing back, but by estimating as accurately as we can and communicating our estimates, and our results, with the customers. We trust, based on long experience, that faced with the best possible information, they ll make the best possible decisions.