After shipping the productor at least making the Install filethe customers took the programmers to lunch at Red Hawk for a little celebration . There must be food is a core XP principle, and Chet and I have our dials set to ten on that one. During lunch, we discussed what the stories should be for the next iteration or two.
One popular idea was to have a File/Save menu so that the customers can use the program and save the output for use in TextPad. We pointed out that we could use copy and paste, if we wanted to defer that story.
I just noticed a bug: when I am typing low down in the window and hit Enter, the window doesnt scroll up to show the cursor. I have to use the scroll bars to make it do that.
Except, of course, it isnt a bug. There was no story for that behavior, and there was no test. It was an oversight, on both the customers part and the programmers. This is actually an important distinction for XP teams to make. Yes, it would have been nice had some programmer thought of making this work. Should the programmer have just done it? Not in our opinion, unless the change was trivial. If it would take any work to do, that work wasnt included in the current storys thinking, and therefore theres a new allocation of effort to be made. Allocation of effort always belongs to the customer. Therefore, if we had thought of it as programmers, we would have asked our customers (who are always on site, by the way) and let them decide.
In addition, the customers didnt think of it either. Theres no point in finger pointing and name calling over whether this is a bug. It wasnt asked for, it wasnt tested , and it doesnt work. Wed like it to work: therefore, write a story for it and the team will do it when the customer schedules it.
(I have figured out that the scrolling is actually even more odd than I first noticed. It actually scrolls the window to the top of the page every time I hit Enter. Im making a note of it because it might be a clue for the programmers.)
(This scrolling problem is getting irritating . I might have to give it priority. But I digress.)
This program is intended to be used to enter articles into the XProgramming.com Web site, which is where initial versions of these chapters first appeared. That process includes an XSLT transformation of the articles in XML into HTML for the site. Customers and programmers talked about this at lunch and agreed that it was of high value. We had been thinking that the story would come a bit later on, after more editing commands, after File/Save, and so on. And we were thinking that it might be a big story.
But with our programmer hats on, we got to thinking that almost certainly there are XSLT objects built into .NET and that it might not be that hard to set up a translator and translate a simple file. We already have the valid XSL that we want to use for the translation, in the old manual Web site generation code, so maybe it wouldnt be too hard.
And then we thought about the customer tests for the product so far. Text in, command, expected text out. So why couldnt the test be to put in a simple XML page formatted like an XProgramming.com article, translate it according to the existing XSL file, and check the output to make sure it looks just like the HTML that we get from the old legacy process?
All wed have to do to make that test run would be to set up an XSLT translator, feed it the string, run it, and read out the answer for comparison. The programmers recommended to the customers that the XSLT story be scheduled fairly soon. We felt we could do it in two or three days and that we would learn a lot in that time. Were sure that we can do the File/Save in a couple of hours and that we wont learn much at all. We can do some new control characters to make headers or to insert complex XML structures like those used on XProgrammings Web site, but those wont involve any deep learning either. So, in terms of making the program more useful and in terms of learning as much as possible, we recommended a small XSLT story.