In Defense of XP

Painting yourself into a corner

The biggest discussions I had with my colleagues was around the fear of painting yourself into a corner, i.e. the fear of choosing a design that will somehow make the system so difficult to evolve, that at some point you have to throw it all away and start from scratch. BUFD (Big Up-Front Design) is a consequence of this fear.

XP's insistence on YAGNI (You're Not Gonna Need It) and on "Do the simplest thing that could possibly work" makes people even less comfortable. It looks like XP is encouraging you to hack your way through the project. How can such short-sighted development actually work?

In his great "Smalltalk Best Practice Patterns", Kent Beck points out the design principle that allows creating long life systems by a succession of small short-sighted increments: no duplication at all is allowed. This produces systems with "lot's of small objects" that can be modified, overridden, plugged-in, etc. to modify the system to support new functionality as it arrives. XP claims that following the Once And Only Once rule, the code will always be in it's simplest state and therefore easy to adapt to any changing requirements.

My experience has shown me that this can work, but you have to turn yourself into a real avoid-duplication freak. Most people don't realize just how intense the focus on avoiding duplication needs to be. Using a language like Smalltalk also helps here, e.g. in Smalltalk all methods are polymorphic ("virtual" using C++ speak) and therefore can be overridden in derived classes.

Unit Testing

A typical answer I get when explaining unit testing is "that won't work here, our apps are specially hard to test". Sometimes they are right. Graphical User Interfaces are notoriously hard to test automatically. Strange to hear that from me, as I'm the author of the Win32::GuiTest Perl module. Anyway all this is missing the point. As the pragmatic programmers know, this is not only about testing your app: it is about programming in a way that makes this testing possible in the first place.

Taken from the comp.software.testing FAQ.

Unit Testing: in unit testing called components (or communicating components) are replaced with stubs, simulators, or trusted components. Calling components are replaced with drivers or trusted super-components. The unit is tested in isolation.

Let's see some difficulties that hinder unit testing and how to try to overcome them.

• Our data is not repeatable (because it comes from a market feed or an environment sensor).
  
  1. You can rig your app to save the data into a file and make your classes use this files as input during the test.
  2. You can analyze the data and generate random data with similar distributions. Again rig your test classes to read this random input instead of the live input.
  3. If the above changes seem like to much work, you probably need to rethink your design.
• Our program takes ages to run. Testing it would take hours.
  
  1. As the above quote shows, unit testing tries to test individual classes or functions. I would be surprised if a single class has so long runtimes. You may be thinking about functional testing instead.
  2. Perhaps it takes long because you're talking to a slow db or legacy program. So change your program to talk to some "fake" db class that reads from a hash or some other in-memory representation instead. In one project I had to start programming a GUI before the DB was ready and I didn't want to wait, so I created my objects from some hard-coded data I had in static arrays inside the class. After the DB arrived I only needed to read the data into this objects, but the surrounding behavior was all there!
• How do you test a GUI?
  1. You don't. What I mean is: try to keep as much of the code as possible out of the GUI, so that it can be tested in isolation. If you do it well, the GUI will be trivial to test even using manual testing.
  2. Use a key recording and playback utility. In VB you can use SendKeys. In Perl use my Win32::GuiTest module. You can also buy several commercial ones. Be careful though. Maintaining this type of tests is a full time job and you need to apply sound software development techniques. Treating them as throw-away code just doesn't work.

Collective Code Ownership

The original XP manifesto says: "To code fast we need to be able to change any class". What this means is not waiting for Tommy (who is on holidays and wrote the Account class), because we need to add some functionality.

Some experienced programmer friends of mine don't seem comfortable with this idea. It goes like: "Look, I wouldn't have a problem if you modify my code, but the idea of that kid we hired out of college modifying my infrastructure classes gives me the creeps".

Two reasons you can trust the changes more on an XP project than on any other project: the unit tests you wrote for your original class must still be working after the changes and the new kid is going to do the changes as part of a pair, possibly with a more experienced colleague.

Also contrast the following two scenarios:

• I know this code is horrible, but Mac is very defensive about his code. He's not going to like it.
• This is a hack and we know how to fix it. Let's fix it and make sure all the unit tests are still running.

One more time: I don't think this means being responsible or having to maintain all the code. It means being able to change any piece of code with confidence if it is needed.

Pair Programming

Sounds radical, but is actually a "old" technique. This article by Dr. Randall W. Jensen talks about a 1975 project using two-person (2P) teams with impressive results:

"Why were the results so impressive? A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walk-throughs, mentoring, and motivation."

This article is also available as a presentation here.

There are several advantages I noticed since I've started pair programming:

• I am much more focused. My attention doesn't wander of. I am more reluctant to check my mail while my partner is in the same office.
• Just thinking about having to explain a particular hack to my pair, makes me avoid the hack.
• Ties in nicely with collective code ownership. At least two people know how each piece of code works. Ever had a problem with somebody leaving your project prematurely? I had. Pair programming mitigates that effect.
• Brings new people up to speed. Your pair already knows the source code layout and how to solve the problem in the context of the body of code you already have. On the other side the new person can bring in new ideas (let's use for_each instead of iterators, might be a good example for C++).
• You learn a lot from your pair. I've been working with people who know more UNIX than I do. I learned a lot there. Now we're back in Windows land and they are picking up things from me.