As we add some new tags, we notice that it s a complex and awkward task. Tempted to document how to do it, we improve the code instead. It looks like a win all around.
One thing that happens on XP projects is that as time goes on, certain things start looking easy. I recall several visits with one client that make my point. One aspect of their project was that they had to compare a series of inputs from one source with a series from another. From each source, a number of values had to be picked up and summed, and the total had to be compared with the summed values from the other sources. But the key values in the two streams were not the same. The team had to create a hand-crafted query to make each comparison group .
When I first visited these folks, these comparison groups were estimated at some large number, perhaps five days for each one, because the first one they had done required five days. A few weeks later, I visited them, and in the planning meeting they were estimated at a day each. I asked why, and the programmer who was working on them told me that he was getting pretty good at it. A few weeks later, I visited them again for the planning meeting. The customer mentioned that she wanted to schedule as many of these comparisons as could be fit in after other things she needed. The programmer said, Give me the rest of them. I ll do them all. We were all surprised and asked what happened . He said that he had gotten bored doing them manually and had created a tool to help him.
You probably remember similar situations, where at first something you needed to program was slow and time-consuming , but you got better and better at it. It s a common effect in most every project, even without building any specialized tools.
I think we re at a point like that here. My customer wants some stories about inserting new tags, and some of them are rather tricky. But I m feeling as if the code and I both have a good grasp of how to do tags, so I m signing up today, not for a specific number, but for as many as I can do. I m promising to do at least the <UL> and <OL> tags, the ones for ordered lists. In Chapter 23, Planning Interlude, I originally estimated them as requiring two days for the first one and one day for the second, but I have a good feeling about them right now and I think I can do them both, and maybe more, in one day s session. We ll see what happens.
The code we ll be looking at in this chapter will receive quite a bit of well-deserved refactoring. In a perfect world, the changes we ll make here might have been discovered sooner and done sooner. In my world, which is very imperfect, that doesn t always happen. It is tempting, when we run across some code that needs improving, to go ahead and improve it. In small doses, that s probably a good practice. I would be concerned , however, about starting an effort to clean up a lot of code on general principles. It s probably better to wait until the code needs changes and to clean it up as part of a customer-driven effort.