Agile development methods – of which Extreme Programming (XP) is the best-known – have breathed life back into academic development methodologies, and have produced wonderful contributions that resonate with all programmers.
However, adopting Extreme Programming as a pure approach on medium to large-sized projects is not prudent: it is not a methodology to be used in isolation; rather it should complement extant, proven methodologies.
By the same token, I would not recommend a pure RUP approach to systems development either: the XP camp has too many interesting productions to offer the community to be ignored. A hybrid approach to systems development is the only way to go.
Good architecture doesn’t just happen
How on earth do pure XP projects end up with a holistic architecture? Apparently on XP development projects the architecture “evolves”. “It just happens,” I have been told.I’m sorry, but good architecture doesn’t just “happen”. Good architecture is the result of forethought and planning by experienced architects and developers working in the context of clear requirements. XP-ers maintain that teams can just start building a codebase, and that it will magically become maintainable, scalable, or whatever else is required for a given system.
Software architecture is sufficiently complex that without some direction and leadership, an unruly mass of disjointed concepts will be the result. Most of you out there (including myself) will have been witness to this.
75% (or so) of the total cost of a software system will be incurred during the maintenance phase. Those thousands of lines of code written by long-gone programmers still need modifications and extensions to continue delivering business value many years after the last champagne cork has popped in celebration of its successful delivery. Given that this is where the real buck ends, I have to wonder about the maintainability of software that is constructed in such an ad hoc manner as seems to be the case with XP style development.
So, how does the XP camp propose that the codebase evolves into something cohesive? Oh yeah – right – pair programming. Joe Junior is going to help Helen Hotshot implement the next phase of her custom marshalling routines for the persistence layer because it’s their turn to pair. Umm… yeah, OK then. Joe would probably be better off perusing the model (UML – you do model, right?) and perhaps get cracking writing some Unit Tests against Helen’s proposed implementation. He may even start to “grok” what’s going on and be truly productive.
But don’t get me wrong – pair programming is awesome – at least it has been the way I have experienced it. On a recent project I paired up with a very experienced database developer and learned a great deal while working out some gnarly PL/SQL.
I was disappointed to recount this experience to an XP guru who told me, nope – that wasn’t pair programming. Why? Because each of us took too long while driving. You see, when real XP-ers get pairing, they apparently slide the keyboard back and forth very frequently. It’s a dynamic, heady mix of sport and programming – you get the picture.
All that keyboard sharing means – yes, I confirmed this – no time to log off. All keyboard bindings and customisations are anathema to REAL XP. What about when complementary tools like XML Spy and such are required? No, real XP-ers all share the same login account. The same one for everybody. Yes, folks: everybody is on par in Pair Programming Land: we’re all Epsilons on this Brave New Project. (Somehow I didn’t think my next pair partners were going to like my IDE’s Emacs keyboard bindings.)
Celebrating indecisiveness
Our industry is in shambles: 74% of software projects fail in some regard (outright, budget, time…), according to a recent Standish Group CHAOS report.What are the major causes of these failures? A top culprit is vague or incomplete requirements which results in building something the client didn’t want. How do hard-core XP teams address this? Why, by involving the client throughout the construction phase (which seems to permeate the lifecycle of XP projects, incidentally). The idea is that you build something, show it to the client, then iterate until you get it “right”.
Working closely with clients (hopefully the end-users) is a noble and intelligent thing to do when building a system, as is getting the client to agree to requirements prior to constructing it. Proposing to iteratively develop a system with “Extreme-ly” close cooperation of the client is a nice idea that can’t work in practice for several reasons. End users generally don’t know what they want – they only truly know what they don’t want. You can’t build systems by process of elimination. Doing so also amounts to admitting that the development team doesn’t have techniques for eliciting requirements with sufficient detail with which to determine how the system should work. It’s a celebration of indecisiveness and a flagrant disregard for the techniques – such as paper prototyping and usability testing – for systematically achieving those aims in a faster and cheaper manner. It’s trial and error; it’s certainly not engineering.
Furthermore, I hold the (sometimes) contentious viewpoint that most clients are actually not even fit to decide certain aspects of a system, one example being the user interface (there are exceptions to this rule, but they are generally very rare). So, I won’t change a quality UI without serious discourse just because some upper management type likes the way some aspect of his two-bit power-browser add-in works. Part of my mandate is to educate my clients in user interface design, and I take it very seriously because I know the impact that this can have on the business value of the software better than they do.
And yes, I need a pay cheque too, so I sometimes find myself unenthusiastically effecting changes that I don’t agree with. I’m opinionated, not dumb!
XP: the coder’s friend
Coders love XP. They get to write code all the time because they throw away tons of code (iterating customer requirements) and even write code to test code. They don’t even have to bother commenting the code because what they write is so “literate” as to not require any. IllBetTheyUseALotOfWellNamedVariablesAsAResult.I’m sorry, but advocating to not comment code is tantamount to professional suicide if you’re a programmer: numerous studies have demonstrated that good commenting improves the readability, maintainability and so many other -ilities.
If you don’t believe me, you only need to look as far as Code Complete; it has the added advantage of being big and heavy enough to hit yourself over the head with afterwards. Hopefully that blow will also help you stop wanting to program in Visual Basic.
The acid test
I’ve got to take my hat off to Kent Beck and Erich Gamma, Unit Testing (à la XP) is a brilliant concept.Unit testing is a lot of things, but mostly it is a way to fool coders into doing more testing. How? Why, by writing more code, of course! How else can you get Joe Developer to do more testing? Joe wants to write code! And I admit that I too love to write code (and presumably you do too, or you wouldn’t be reading this) and I rarely do so without NUnit or JUnit. In fact, I have such reverence for Unit Testing that I now always push hard for test-driven development at client sites. Plan on writing a new class? Plan on writing Unit Tests for it.
However, all is not nirvana in Unit Testing land and Unit Testing is not a panacea for development. Unit Testing is a tool for testing and refactoring code and is complementary to bona fide system testing. The XP crowd isn’t going to do away with legions of experienced, exacting testing professionals anytime soon. This is because Unit Testing is fundamentally flawed for the same reason that Joe Developer’s code is: they’re written by him! (or partially, at least). Unit tests are only as good as the authors, and require experience to develop well. This is compounded by the fact that large Unit Testing frameworks demand a certain degree of design and can become pretty involved. All this to say that the quality of Unit Tests varies greatly and are not all created equal. Crafted by an experienced professional, Unit Tests are manna from heaven for particular development activities; but Unit Tests crafted by Joe Junior will still require a code review and several iterations to become lethal weapons.
Extreme Programming has made wonderful contributions to the developer community and I am a staunch advocate of a few of them. These contributions however should be considered complementary to other successful techniques that have built software engineering into the discipline that it is today and continues to evolve into. The most successful projects will combine elements of the best development methodologies while adopting a pragmatic and tempered – rather than extreme – view of new methodologies.
Edward Garson is a Senior Consultant with Dunstan Thomas, a company that transforms software development at a grassroots level through technology evangelism, architecture, design and process best practices. Edward specialises in OOA/D, UML, XML and uses both .NET and J2EE platforms.
Comments