Title: Taking the Easy Road

The recent interview with Kent Beck about Extreme Programming (XP), in Overload 35, was not my first exposure to its practices. I stumbled across the Wiki site (c2.com/cgi/wiki?ExtremeProgrammingRoadmap) not too long ago, and instantly recognised that I could make use of at least some of the practices advocated there.

One thing immediately stood out from the page which I found difficult to rationalise; "You Aren't Gonna Need It" is (or seems to me to be) a cornerstone of the XP discipline, and describes the situation where you foresee a possible feature or use which is not immediately required but may be in some indeterminate future. 'You Aren't Gonna Need It' says, well, do not do it.

I first thought of "feature creep™", thereby justifying it to myself. More thought placed me in a quandary, however. I had recently read the Effective/More Effective C++ CD by Scott Meyers. I am a self-confessed learner (I hope I never stop being one) and admit to being heavily influenced by Scott's books. Hence, I recalled the axiom "Program in the future tense" (More Effective C++) and perceived a paradox. On the one hand I am advised not to provide for a possible future requirement, and on the other, I am advised exactly the opposite.

(OK so I take Scott's words to extremes here, no pun intended, but to me programming for the future suggests at least making allowances for possible future expansion at the cost of spending more time today).

As luck would have it, I was considering a problem which brought these two philosophies into conflict. I had a requirement to develop a program which, in essence, read a file in a certain format and produced a new file in a different format. As with perhaps all such programs (and many others) it was needed the day-before-the-day-before, and so the aforementioned facet of XP reared its head above my shoulder. As I set about producing a basic design, an image of a CD with "More Effective C++" written on it appeared above my other shoulder.

For peace and quiet, I wanted to reconcile these two opposing views, and meet my deadline (revised to "tomorrow" ;-)).

The rules for the program were very strict - making for a great specification and simple design:

Such problems may be the stuff of student "Introduction to Programming" assignments, but they are also my daily bread. My initial design consisted of little more than the bullets above. A little further thought revealed a flaw, however. I guess you've all spotted it by now: what if the input format changes? And from this question, others arose: what about the output format? The record selection rule? The record layout?

XP said "don't worry about it - You Aren't Gonna Need It (and if you do, handle it then)."

Scott said "You are gonna need it. Face it, it will change. It's inevitable."

Part of the rationale behind XP's thoughts on this are to prevent feature creep and to help prevent the programmer getting distracted from the current requirements. Being easily distracted, it seemed a good idea to me, not to mention being lazy, i.e. don't write anything you don't have to.

However, I also wanted to ensure that my program could be graceful in the event of change, and I believe Scott Meyers when he tells me it's inevitable. I've had to maintain and modify enough programs to understand that.

In the end, it was the Gang of Four who came to my rescue. Enter the Strategy. This is a pattern I first encountered in Design Patterns - Elements of Re-Usable Software [Gamma, et. al.1995]. "Strategy lets [an] algorithm vary independently from the clients that use it." It occurred to me that I could use this technique to provide an algorithm for each part of the problem, and that they could be changed easily in the future to accommodate different requirements. It also means that I don't have to write a large amount of code that XP says I won't use, and so won't get led off the beaten track of the initial specification.

The details were fantastically simple. Each of the four basic procedures was defined by a base class:

I made these abstract so they provided the interface and no more.

Each abstract operation is made concrete by a derived class. In the initial requirements there is only one concrete implementation for each procedure, but it means that the principle is extendible independently of the other procedures:

So, to change the format of the output file to a spreadsheet format, a new class inherits from the File Writer base class, and defines the operations its own way. None of the other operations need to even know about the modifications. Similarly, changes can be made to the internals of one concrete class, which will (should) be invisible to the other classes. More importantly, such changes are transparent to the clients of these classes.

Moreover, it is possible to change the behaviour of the program dynamically, perhaps via a menu. All that would be required are declarations of the required operations. The strategy for each operation could be a class member (held as a pointer to the base class) or a global/namespace scope variable.

With the overhead of describing a base class and a single concrete class for each operation, we have nearly abided by the XP rule of "You Aren't Gonna Need It" but not entirely. However, the overhead is minimal, and means that we have completely abided by the axiom of programming for the future. As compromises go, I think it pleased both parties considerably.

Finally, the program was delivered within the time scale. Even my student "Introduction to Programming" assignments didn't always enjoy such treatment.