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 XP—Do 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 community—programming 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 approaches—some more “extreme” than XP—were 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 conflict—those 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.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment