Another Look: Extreme Programming

Do you know nothing about Java but are ready to learn? More info below. First, though...it’s been a while since I’ve written anything on extreme programming, the programming philosophy-cum-methodology invented and promoted by Kent Beck. Kent wrote the book on extreme programming—literally. In Extreme Programming, Beck argues that it’s time to stop the madness—the madness being the abuse heaped on programmers by managers and their clients who have the power and the will to force programmers to...

1. try to guess at the functionality they need,
2.come up with a GUI that will satisfy all users and
3. have it all ready by Friday.

Enough, says Beck and his prescriptions for doing what he calls extreme programming are the subject of his book. He lays out 12 rules of a new way of interaction between client and programmer. I first read Kent’s book about three years ago when it first came out. I found some of the book’s recommendations brilliant, such as pair-programming and writing tests first. Other of the book’s ideas I found less persuasive. Still, I added the book to the recommended books on my site, www.halhelms.com (under Writings).

During the past three years, an Extreme Programming (XP) movement has developed and spread rapidly. Extreme Programming is now one example of a broader movement known as agile programming that includes other movements such as SCRUM and UP (Unified Process). Agile programming has its own manifesto available at www.agile.org.

As much as I like certain things about XP, I’ve found other aspects troubling. Notably, XP’s insistence of “people over processes” sounds wonderfully egalitarian, but offers no real prescription for how to reliabily, repeatedly produce successful software projects. It reminds me very much of a discussion I had with the CTO of a very large toy retailer who was trying to interest me in taking on the head of their ecommerce development effort. When I asked him about what processes would be used, he told me, “We believe in hiring the best developers and getting out of their way.”

Hmmm…sounds good—almost. But what if a failure results? With no defined processes in place, the inevitable conclusion must be that the developers involved just weren’t among “the best”. “Blame It On the Developers” may be a popular strategy but hardly one I wanted to endorse and I declined the offer. (Subsequently, the company’s ecommerce site failed spectacularly under the stress of a Christmas season.)

After an initial bout or two with XP proponents, I remained silent about my growing concerns. I really didn’t know that much about XP, after all. Maybe I was missing something. So, I was particularly happy to find that Kent Beck and I would both be giving keynote speeches at the Canadian Undergraduate Software Engineering Conference (CUSEC) to be held in Montreal. Maybe hearing it straight from the source would allay my concerns.

I had developed my own methodology based on the premise that “Clients can’t tell us what they want until they see it.” That single insight had spawned such things as wireframes, iterative prototyping, DevNotes, query sims—a list of practices that was later codified to some degree and given the name “FLiP” for “Fusebox Lifecycle Process” although the methodology was agnostic on which, if any, framework the developer chose to use. (Nat Papovich and Jeff Peters have a long section in their book, Fusebox: Developing ColdFusion Applications, on FLiP.)

I find that FLiP works wonderfully well when there iss a central program architect who can exercise a considerable degree of power over the way the software development process worked. But when the client (or, God help us, a manager) is driving the process, FLiP won't work.

Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors

If clients can refuse to go through the stages of FLiP, the developer is at their mercy. You know the old definition of insanity—doing the same thing time and again while expecting different results. I knew what happened when clients drive the process—and the results were ugly. It was this “process” that brought us the 70% failure rate for custom corporate software reported by the Standish Group and others. Could XP be the answer for situations where developers’ ideas for the software development process are not welcome? With all this fermenting in my brain, I headed for Canada.

I heard Kent give his talk. Later, we were able to speak privately about XP. My impressions? XP sees programmers as coding machines. You insert a “user story” and out comes code. Now, these are very smart coding machines and they can integrate the code for one user story with the code produced from previous user stories, but they cannot actually design in the sense of creating a coherent architectural plan before any coding is done. In XP, architecture is done by a process of refactoring—architecture by discovery, as it were.

XP is concerned that users of these coding machines not abuse the machines. Beck stated that his goal was to equally divide the dissatisfaction among client and programmers in distinction to the more common arrangement of pushing the problems onto the developer. It seems to me that XP’s rules are all based around this idea: don’t abuse the (coding) machine.

This concern for programmers is laudable, but I must admit that it contrasts distinctly to my vision for coders, whose role I view to be more consistent with artists, writers or composer than punch presses or milling machines. Still, it must be admitted that many developers find themselves in jobs where they are treated as a machine. My advice for programmers caught in that bind is this: do whatever you need to do to survive (including pushing for XP’s adoption)—but create a plan for extracting yourself from a dysfunctional situation.

To date, XP suffers from a lack of any serious successes. The poster child for XP development, the Chrysler payroll system, was subsequently cancelled. In the absence of evidence of success, the claims for XP’s success by some of its adherents (NOT including Beck) become more urgent and more strident. But as the French observed centuries ago, “Rien ne reusscit comme le success”—Nothing succeeds like success.” FLiP has some notable successes on both small and large projects; having some from XP would be most helpful.

One phrase XP advocates echo is “stopping the pain”—the pain caused by the dysfunctional development process. Certainly for people in pain, nothing else may matter. That’s completely justified. I hope, though, that we can produce something that does more than this—that “lets ordinary developers achieve extraordinary results.” That’s the mission statement for FLiP—but it does mean that developers must have a certain degree of power in the process of creating software. Where such is not possible, XP may well "stop the bleeding."

Do you know nothing about Java or object orientation—but want to learn? If so, hurry to register for my “Java for ColdFusion Programmers” class. It’s March 3-7 in Washington, DC. Hurry, though: it’s filling up quickly. You’ll learn about what makes developing in objects so different from procedural coding. You’ll then use this knowledge to learn how to write object-oriented programs in Java. It’s an intense but very rewarding five days of hands-on coding and personalized instruction. Registration at www.halhelms.com.