|Ernesto Guisado's Website » Programming » Extreme Programming » In Defense of XP||Articles | Miscellanea ||
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.
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.
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:
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: