Initial Vision

The team in this book is mostly me, Ron Jeffries. Im getting help both in ideas and programming from Chet Hendrickson, one of my co-authors on Extreme Programming Installed (Addison-Wesley, 2001). Chet will be pair programming with me at times throughout the book and helping me figure out what to do next . Ill be programming alone much of the timewhich as an Extreme Programmer Id rather not doand Ill be getting other pairing help when I can. Acting as XP Customers for a while, Chet and I came up with a vision for a project.

My Web site, http://www.XProgramming.com , is mostly generated from XML input, processed through some Ruby code to produce the indexes and through XSLT to generate the Web pages in a consistent format. (An example of the format appears at the end of this chapter.) The XML format is pretty simple and straightforward, but its a bit awkward to type in, because you have to embed all your paragraphs in <p></p> tags and use other tags for sections and headings and the like. Our starting idea is for a tool to help with this job. Our amazing dream vision goes like this:

Theres this WYSIWYG editor that looks just like an XProgramming.com Web page. You can type anywhere and edit the page. With a few simple control characters , you can select any of the special format items that the sites XML can contain. The page takes shape as you watch.

Now this is a grand vision. However, while it might be a decent initial idea, its neither specific enough nor practical enough to build in XP style. To build a product in XP style, we need to break it down into small features that can be built in a week or so. On a real project, this would be a collaborative effort between the Customers and the Programmers, talking about whats possible, understanding the vision, understanding what the important aspects of that are, and so on.

The good news is that since Im acting as both Customer and Programmer (with Chets help), there wont be much disagreement . But the bad news is that it will be easier to lose track of delivering value. As programmers, we often get excited about some technical problem and we start working on that prematurely or too much, at least from the viewpoint of delivering features. Of course, we always say your features will be easier and cheaper if we work on this first. In my very experienced opinion, this is almost never really true, and as you read along in the book youll find out why I believe that and the extent to which Im right.

Anyway, in a bit of a split personality kind of way, we immediately started working as programmers (thats us) with our customers (thats us too), talking about feature stories, value, and cost estimates. Since we didnt know how to program in C# at all, our cost estimates were pretty rough. But on the other hand, our customer (thats us) trusts us.

We fear ^[1] that WYSIWYG editing will be expensive, because of the difficulty we expect in figuring out where the cursor is, when typing into a formatted Web page. When an XP team is too ignorant to estimate the difficulty of something and afraid that it might be expensive, its time for an experiment. So with this initial vision in mind, Chet and I undertook a few simple experiments.

^[1] We like to use the word fear where other people might say concern or worry. We find that the sooner we acknowledge that we are afraid of something, the better equipped we are to deal with it. You should use the terms that work best for you.