Edge Of Chaos

This balance between rigidity and anarchy is the core difference between XP and the methodologies that came before it. Predecessors were focused only on fighting chaos; XP recognizes that stasis is just as dangerous.

There was a lovely diagram of this EdgeOfChaos concept, I think I saw it on XpDay? '02 (UK ExtremeTuesdayClub conference). Does it have a name? A URL? Maybe I saw it in ExtremeProgrammingExplainedEmbraceChange? Or the green book whose name I forget...

The ScrumBook talks about EdgeOfChaos and has a diagram showing two axes (complexity and instability of requirements, I believe), and different regions showing project-type (from ordered to chaos). Couldn't find a URL for it though.

Laura Hill and I put together some ideas a couple of years ago about how a number of phenomenon seen in other dynamical realms have emerged in XP practices. See: http://www.laputan.org/chaos/chaos.html.

If you are having trouble telling XP apart from one extreme, it is probably because you are on the other. People who have spent all their life in New York City have a hard time telling Ohio from Oklahoma.

A complete description of a method takes many volumes. I bet that there have been 10 volumes written on UML and its associated method. I've been periodically receiving these volumes. The books claim that they only introduce the method, that if you want to learn the complete Rational UML method then you have to buy a lot of other stuff that is a lot more comprehensive than the books.

XP is going to take several volumes, too. See WhosWritingAboutXp. A few web pages to describe it seems to be enough for some people to think they get it, but not others.

What makes something a real methodology and what makes it a pseudo methodology? A real methodology doesn't have to be the best way to do something, it just has to be a repeatable way that you can teach to somebody.

-- RalphJohnson

The page XpIsaPseudoMethodology? (which was mostly refactored into this page) was about one initial reaction to XP as it was evangelized early on wiki and the clash of it as communicated with a working environment which exhibited in remarkably similar form many of the XP practices done wrong. At the time, it happened that the practices XP advocated resonated remarkably badly with what seemed to be the forces that made the working environment seem to be a host of AntiPatterns. In my judgement, at the time, the source of most of the difficulties at my employer were

• User requirements were gathered in a disorganized way and little was written down coherently.
• The time frames for development were set arbitrarily by business drivers with no input from the development team.
• Individual programmers on the team were in general mavericks with little or no shared professional practices. (The author now humbly realizes his own maverick tendencies at the time).
• What little process and documentation there was rarely rose to the level of sufficient to realize the potential of the skills of the development team and the ideas of the business.

At the time and according to the way it early advocates explained it, XP seemed to take all of the things the team wasn't doing (and by my judgement causing the development to fail) and make virtues of them. Part of it was the somewhat breathless and evangelical style of the explorations, and part of it was just my failure to understand (and keep up with) the development of XP.

Some specific examples:

KentBeck seems to be allergic to paper; at the time my judgement was that my team need more written documentation, not less. In particular there was some very odious code from a couple of years back that was a NoGoArea because it was written by the first hotshot developer, since departed, and nobody knew exactly how it worked, but it was critical to the system.

Our business customers essentially had no acceptance process. All we could do was install the software and wait for the bug reports and flat-out snide complaints to come in. Again, in my judgement at the time we needed more written requirements documents, and plenty of UML diagrams to design a solution and "verify" it before coding. In my naivete I believed that we would find a small but smart group of business users who would learn to read UML and participate in the requirements tracing.

Finally, testing. I wrote "Code/compile/run repeated until it seems to be free of bugs". I had virtually no exposure to UnitTest frameworks. A test to me at the time was what might be termed functional test, and because we didn't have documented requirements (remember my obsession with paper) there was no certainty that what the programmer thought was working functionality was in fact anything more than code free of obvious logic and performance bugs.

Have you figured out yet that I was an amateur programmer at the time I wrote this page?

I could write a lot more about each XP practice and how the explanation and my perception and environment conspired to make the whole thing seem like a way to avoid doing the things that I judged were necessary for a successful development effort, but I hope this is sufficient.

Of course, the universe works in mysterious ways, and for a while I held a position at an employer that had officially licensed and adopted RUP and was in the process of customizing and implementing, and most of my co-workers thought of me as "the XP guy".

-- StevenNewton

When the company you're working in is in chaos, it can seem that ExtremeProgramming is nothing more than giving a name to a collection of poor programming practices. Here's what a lot of programmers doing the job under bad conditions do: Given a customer with an unrealistic requirements and schedule and understaffed project, just pick a piece of the purported requirements, make a guess at what it means, start coding. Code/compile/run repeated until it seems to be free of bugs, then ship it (or commit the changes or whatever constitutes a release). Given XP's dislike of written documents and other heavyweight artifacts, it might seem as if XP is encouraging this slack state-of-affairs. However, the differences between XP and total chaos, as subtle as they are, are essentially important.

When I first starting reading about XP (all of 2 months ago), there was instant recognition: an agile method that works with the realities of developing software as a consultant.

Far from poor programming practices, these techniques (or suggestions as I like to think of any set of methods) rely upon good programming and develop good programmers.

Software is complex. In our world that complexity is often hidden in the consumer nature of the products familiar to most clients. It's not that shrink-wrapped software isn't complex, it's that the cost of that complexity is spread over many consumers. In short, custom software tends to be expensive (choose your metric).

The basic set-up of having too-short time limits on projects isn't likely to change. XP helps quantify the equation and sets up an approach that should help projects succeed. That's the bottom line: does it work?

I'm new to XP. And my hunch is that you are too. I wonder if after you try some of what's suggested on a real project what you'd think then. To me, the suggestions seem eminently reasonable and many codify my own practices. I build good code. I've never been on a project that didn't go live. I've never been over-time or budget by more than 10%. I have confidence in my practices.

Will I abandon UML? Not at all. I see UML and XP working well together.

So I think that (a) XP tries to generalize good practices and (b) the reality of much software development does occur under bad conditions - so what to do about that? You can't just pretend the problem's not there. XP promotes lots of communication. Programmer to customer/client. That's a big part of the fix.

-- EzraEpstein

Every so often, concepts emerge (from existing practices) that radically simplify a field. In the early 80's, RISC replaced CISC. Now we see s/w design methods getting increasingly complex. Perhaps, contrary to the original comments, ExtremeProgramming is doing a Copernicus to UML's Ptolemy. -- DaveWhipp

Going back to Steven's original metaphor, I assert that traditional programming methodologies are "Ptolemy's terribly complicated but ultimately wrong system" while ExtremeProgramming is "Copernicus knock[ing] the earth into its proper place". Correct me if I am wrong, but wasn't Copernicus branded as a heretic and put into jail for saying that? At the time no one wanted to hear the truth. -- DonWells

You're wrong. Copernicus was never branded a heretic, nor was he ever jailed. At the time a lot of people wanted to hear the truth. Copernicus's work was banned, though. http://www.astrosight.com/copernicus_to_newton.htm [offline; perhaps replace that link with: http://www.geocities.com/CapeCanaveral/Launchpad/4515/HISTORY.html#Galileo]

This is definitely good news for Kent!

(He's thinking of Galileo; censured by the Catholic Church for publishing work based on Copernicus' sun-centered ideas. A lot of history is being misinterpreted in this thread. ;-)

Copernicus did not OnlySayThingsThatCanBeHeard

For a consensus on Copernicus, see http://en2.wikipedia.org/wiki/Copernicus. For the source of the confusion, which appears to be Galileo, see http://en2.wikipedia.org/wiki/Galileo_Galilei.

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006