Communications of the ACM
Communications of the ACM
Technical Opinion: Programming Extremism
The battle lines are drawn. Hostilities have broken out between armed camps of the software development community. This time the rallying cry is, "XP!"
At recent OOPSLA conferences advocates of Extreme Programming (XP) made themselves conspicuous with their red "I XPDo You?" badges. Some well-known authors and consultants in the OO community reinvented themselves as preachers of XP; others muttered under their breath about the end of the world.
If you've been in a dark cave (or cubicle) for more than a year, and you somehow haven't heard about XP, it's a lightweight OO development process. Like all good religions, XP is built around a codifiable belief system and a collection of practical techniques. These techniques include small teams, pair programming, JAD with business stories, very short development iterations, automated testing, and discovered design. This is not a general introduction to the EXP methodology. Those interested should refer to [1, 2].
What XP uncovered (again) is an ancient, sociological San Andreas fault that runs under the software communityprogramming versus software engineering (a.k.a. the scruffy hackers versus the tweedy computer scientists). XP is only the latest eruption between opposing continents.
Which brings us back to the OOSLA conferences. Imagine you were an anthropologist moving invisibly among the social cliques at OOPSLA. If astute (and politically incorrect) enough to risk some broad stereotypes, you might discern two opposing belief systems (see the table).
If it weren't for Microsoft bashing, what would ever bring these tribes together? They resemble Republicans and Democrats battling ideologues caught up in the divisive dualism of either-or positions on hot-button issues (while the rest of the country rolls its eyes and stays home from the polls).
But, just maybe, the software development world isn't black-and-white. Maybe it's a fuzzy grayscale. For example, there have been projects where "hack (er, prototype) until it works" RAD approachessome more "extreme" than XPwere successful, even tactically appropriate. I've seen a few. However, in some cases I later saw those same RAD teams try applying their techniques to other kinds of efforts, only to fail disastrously and wonder why.
At the other extreme, I've also watched helplessly while a high ceremony heavyweight process brought an organization of talented, formerly productive software engineers to a dead stop. Crimes were committed in the name of SEI CMM and ISO 9001. Yet, eventually management had to let go their dreams of Malcolm Baldridge awards and let their people get some real work done.
On the other hand, I once had the privilege to observe an organization achieve CMM maturity Level 41 certification without the baggage of a productivity-killing, paperwork-clogged high ceremony methodology. Lean, mean ... yet mature.
An XP evangelist2 recently accused the Software Engineering Institute of setting back the practice of computer programming. Now certainly CMM has been abused, but this attitude betrays a misunderstanding (and mistrust) of software engineering's goals. The goals are worthy, and (surprise) they can even be implemented with lightweight methodologies where appropriate.
It would be enlightening to conduct a CMM assessment of a team successfully practicing XP. In theory, I see no reason why the XP team should not achieve a maturity level of 2 or better. CMM Level 2 is about managing project requirements and schedules effectively and repeatably. XP claims to do just that, using story cards and a planning game.
On the software engineering side of the fault line, there is an equal amount of misunderstanding and mistrust. Superficially, XP resembles RAD in some respects, and at least as many crimes have been committed in the name of rapid prototyping as in the name of SEI CMM. Yet, as with CMM, in many such cases RAD itself was less to blame for its failures than were the people who misused it. Besides, XP theoretically demands a level of discipline and rigor well above RAD.
It's time to stop the methodology crusades. A one-size-fits-all development process does not exist. Software projects vary wildly in technology, size, complexity, risk, criticality, regulatory, and cultural constraints, and many other key variables. Alistair Cockburn3 has done insightful work mapping out the spectrum of software projects, and the parallel Methodology Space. He argues persuasively that there is a sweet spot where XP will flourish, mainly on smaller, less critical projects.
What's needed is not a single software methodology, but a rich toolkit of process patterns and "methodology components" (deliverables, techniques, process flows, and so forth) along with guidelines for how to plug them together to customize a methodology for any given project. My own work led me away from one-size-fits-all methods, and toward tailorable process frameworks based on proven best practices.
By recognizing each project's unique needs and circumstances, and giving them the flexibility they need to succeed (while balancing their parochial needs against strategic goals of the enterprise to improve reuse, quality, cost, and so forth), we found corporate development guidelines gain more acceptance from development teams. A process rejected by practitioners is doomed to fail. Methodologists, managers, and Software Engineering Process Group police must resist the temptation to blame such rejections on the so-called practitioners, which would be like the Coca-Cola Company blaming consumers for the failure of New Coke.
Even if XP is best suited only to certain projects, it ought to be one of the tools in our bag of tricks. How often (if ever) one actually uses XP (or any other process) becomes a matter of project circumstances, not religious beliefs.
The dream (now misguidedly advocated by some members of the Object Management Group) of a single, standard grand unified process is fool's gold. It would be much more useful to collaborate on a series of process frameworks, or a meta-methodology, based on abstractions of proven process patterns. Under certain project conditions, XP might be an instantiation of the framework. Under other conditions, something like RUP4 or OPEN5 might emerge. Robert Martin has even demonstrated that XP can be viewed as a sort of degenerate case of RUP.6
In the end, we're still left with the underlying social conflictthose scruffy programmers and tweedy software engineers pitted against each other. Even if the XP issue is defused and the current furor subsides, another conflict seems likely to erupt again.
If the opposing groups are like Democrats and Republicans, then maybe what the software development community needs is a Reform Party. Is there a disaffected, apathetic silent majority that is neither scruffy nor tweedy, that isn't violently emotional about methodology? You bet there is. Most of us want tools that work, not religious dogma.
Who speaks for the pragmatists? It's time for a third party in software development politics.
References
1. Beck, K. The XP Bible Remains Extreme Programming Explained: Embrace Change. Addison-Wesley, Cambridge, Mass., 1999.
2. www.extremeprogramming.org; www.XProgramming.com; or /c2.com/cgi/wiki?ExtremeProgramming.
Footnotes
1On a scale of 1 to 5, as assessed by the SEI. Most (90% by some estimates) development organizations never even reach Level 2.
2Ron Jeffries, speaking at the Current Object Practices and Experience conference (COPE '99), St. Thomas University, St. Paul MN, 11/16/99.
3Cockburn's writings on Methodology Space are available from the Humans and Technology Web site (members.aol.com/humansandt/). Especially recommended is his article "One Methodology Per Project."
4Rational Unified Process, a relatively formal OO development process derived in large measure from Ivar Jacobson's Objectory, but now marketed by Rational Corp. under this somewhat misleading name. Recently RUP has moved belatedly toward a flexible framework in an effort to embrace (or co-opt, depending on your point of view) XP (see also footnote 6); www.rational.com/products/rup/index.jsp for more on RUP.
5The OPEN group, a consortium of companies and individuals, propose an alternative process standard. It rivals RUP, but remedies some of its shortcomings. In its second version, OPEN was already evolving to more of a framework than a fixed process before the advent of RUP or XP; www.open.org.au/.
6Rational's latest Unified Process is rubbery enough it can be squeezed and stretched to look almost like XP. Robert Martin dubbed his "extreme RUP" dx (read it upside-down); www.objectmentor.com/publications/RUPvsXP.pdf.
©2001 ACM 0002-0782/01/0600 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.
No entries found