Extreme Programming (XP) Holds Promise
For Intranet Development - Part II

Code and test

Being an iterative methodology, XP is similar in spirit to rapid prototyping, in which testable units of limited functionality (prototypes) are produced early, verified, then fleshed out with optimized code and tested again. Prototypes can be very effective for verifying user interface design before implementation details have been worked out. But while XP agrees with this emphasis on testing, it strives for productivity by insisting that developers work at all times on deliverable units of code rather than mock-ups.

Accordingly, unit testing is an essential part of the extreme programmer's daily routine. Unit Tests verify the correct functioning of units of code - classes or components, in the case of object-oriented development, or DHTML pages, scripts and servlets in the case of Web projects. If you're using Java, you can take advantage of JUnit, a Java-based framework for unit testing. XP is implementation-neutral, though - it was originally created to expedite development in the Smalltalk language - so with a little experimentation you'll be able to find the right unit granularity for your project.

While unit tests are the developers' responsibility, Acceptance Tests come from the customer. No User Story is complete without one or more testing scenarios. Releases are marked by the successful completion of Acceptance Tests, which verify that a particular User Story has been realized in code. Releases are intentionally kept small to maintain project velocity and to allow for errors in the specification process. The idea of producing systems incrementally by assembling tested units into small releases did not originate with XP. In a 1986 essay titled "No Silver Bullet," Frederick Brooks, Jr. recommended that systems "first be made to run," then fleshed out "bit by bit," so that "one always has, at every stage in the process, a working system." (The essay appears in the 20th anniversary edition of Brooks' seminal critique, The Mythical Man-Month: Essays on Software Engineering - must reading for anyone involved in creating or maintaining computer systems.)

This notion of having a working system almost immediately and iteratively refining it, in a sequence of releases prioritized by the customer, is XP's way of guaranteeing the customer's right:

• to see progress in a running system, proven to work by passing repeatable tests that users help specify
• to cancel at any time and be left with a useful working system reflecting investment to date.

These benefits alone justify your consideration of XP. But there's more.

What happened to design?

One of the more controversial aspects of Extreme Programming is the secondary role XP assigns to what it calls Big Design Up Front: methods of software development where a "big" design is created before coding and testing take place. In UML, for instance, extensive modeling, analysis and design steps precede implementation, often by months. UML attempts to cope with the instability of user requirements by abstracting stable superclasses from which changeable subclasses can be inherited, in theory facilitating evolution and limiting the impact on existing applications. XP, by contrast, advises against "future-proofing" code through architecture, prefering instead to meet small sets of current requirements quickly. Two representative extreme programming practices are "Do the Simplest Thing That Could Possibly Work" and "You Aren't Going to Need It."

The belief behind both slogans is that simplicity pays. "If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy. Put in what you need when you need it," Kent Beck says in Extreme Programming Explained: Embrace Change.

Not that XP rejects design and architecture. It just puts them behind generating tested code that satisfies users. That goes along with Frederick Brooks' advice to always have a working system - not a design manual full of diagrams. By cleaving to the User Stories, XP ensures that developers stay focused on coding and testing artifacts of demonstrable business value. XP back-loads design, relegating it to refactoring, "a technique to restructure code in a disciplined way," according to Martin Fowler, who wrote the book on the topic. Under XP, design evolves as programmers continually revise their code towards the simplest, least redundant implementation, a practice called "Refactor Mercilessly." Largely to support this goal XP requires programmers to work in pairs, with one testing/refactoring while the other codes, and vice versa.

That, in a nutshell, is what XP is all about. Let's briefly consider how the approach fits the needs of intranet stakeholders. Big Design in general and UML in particular have limited appeal in such projects, for two reasons. Lots of up-front architecting fosters an adverserial, us-versus-them culture between IT and the the lines of business whose use of the intranet will determine its success. Second, UML requires a large up-front commitment from users and developers, delaying the site's benefits without any assurance that the investment in architecture will pay off. Faced with change on the scale of Internet time, simplicity and rapid release cycles are more likely to succeed than anticipatory features and future-proof designs. XP holds promise because of its velocity and its focus on working code that reflects user stories.

In addition, the deliverables of intranet applications have the right granularity for XP testing and refactoring. DHTML Web pages, Active Server Pages (ASP), Java Server Pages (JSP) and XSL Transforms (XSLT) lend themselves well to both unit testing and customer-facing acceptance testing. So do CGI scripts, Java servlets and properly factored components based on Enterprise JavaBeans (EJB) or Microsoft COM. The J2EE platform offers a clean migration path for refactoring applications from JSP/Servlets to EJBs, while a similar path exists on Microsoft servers from ASP to COM+. XP suggests that in many cases these refactorings can be undertaken incrementally on working code, without tectonic architectural shifts.

Finally, intranets provide excellent soil for XP's feedback mechanisms to take root, since the stakeholders typically work for the same organization. Whereas it may be impossible on a B2C or B2B Web site to ensure sustained customer-developer communications, it may well be practical when building a B2E (business-to-employee) site. I hope this article has piqued your interest in XP and whet your appetite for trying some of its techniques on your next Web project.

Gordon Benett is a technology strategist with over 16 years experience analyzing, architecting and developing information systems. He is currently with Aberdeen Group (Boston, MA), where as a Senior Research Analyst he follows the Enterprise Java and Middleware markets. Gordon founded Intranet Journal in 1996 and remains a reader and contributing author. He welcomes your comments at gbenett@mediaone.net.

Printer Friendly Version