Nonlinearity Of Xp

What Ron and Kent are saying is that doing 90% of the XP practices gives you (e.g.) 75% of the value of XP, and to get from 75% value to 100% value, you have to go from 90% to 100% of the XP practices. That nonlinearity is certainly interesting to note and discuss. -- AlistairCockburn

I don't know whether this is about ExtremeDiscipline or some other issue, but Kent has long mentioned the sympathetic effect on one XP practice of other XP practices. The nonlinearity of the set of practices, each individually useful, together better than all separately. Ron mentioned the rapid dropoff in effectiveness when they went from 100% use to 90% use (numbers included for illustrative purposes only - Alistair's lawyer) -- Alistair

Ward talks about the book TheAthleticSkier, where the authors suggest agressive skiing be the norm, even among recreational skiers. Much of the book has to do with getting your boots and balance just right. They point out that being a little out of balance isn't much better than being a lot out of balance. In other words, you won't see much improvement from tweeking your boots until they are almost exactly right. Then small changes make a big difference.

This is the opposite of the EightyTwentyRule that most of us live by much of the time. The best explanation I have is that in systems with controls that don't interact much, some are bound to be more important than others, and if you find the important controls and manipulate them you'll get great effects.

In a system governed by the TwentyEightyRule, the controls all interact with each other, often in non-obvious and non-linear ways. In such a system, certain combinations of control settings give really good results, and lots of combinations don't work well. Hence, in the skiing example, there are lots of ways of skiing that don't work well (I know, I've tried many). But there a bunch of things that, if done together, give dramatic improvement.

Another example of a system with interacting controls is a SaltWaterAquarium?. JoelSpiegel? told me about setting one up. Apparently it is very frustrating. You put in more acid, and all the fish die. Then more base, and all the fish die. Then you raise the temperature, and all the fish die. And on and on. Then, one day you get all the controls just right and the whole ecology "pops" (that's the technical term for it). Once it has popped, it is actually quite difficult to destabilize.

When I say that you need to be doing all of the practices to be doing XP, it is from this perspective, not from a desire for WorldDomination or a naive idea that I can dictate how every project behaves.

-- KentBeck

I never thought you were trying to move to Redmond ;-) or be a master controller. But the question I have based on salt water aquarium and aggressive skiing metaphors is this: what kind of team and what kind of organization do you need to be in where this subtle difference in balance allows you to achieve 100% XP?

I don't want to rain on your parade -- I think you guys are doing great things, I like reading your magazine articles, and I like browsing your pages here on the WikiWikiWeb. But let me describe a scenario that might counter this 90/100 percent thing.

In the middle of December 1998, I was told to show up in my manager's manager's manager's office for a meeting. In it, there was an MD and a senior architect from the fixed income group. One of the windows in the office gave us a beautiful view of the FlatironBuilding. And seconds into the meeting, I was told that the firm needed a really critical project to be executed successfully that had all kinds of crazy performance, scalability, and functionality requirements. Major business drivers were in place. Me and this architect guy were to architect, design, and build it.

In April we deployed v1.00. It was a smashing success! Users loved it, the MDs loved it, helpdesk loved it, people who looked at our design and code loved it. And we the people who built it loved (were proud of) it. Horaaay, right?

But when I look back at the context we were in as we built it, I might have been fired if I tried to push using XP 100 percent. By using the tools that had the most value to us based on our situation -- whether it was RogueWave, patterns, raw COM or ATL-based COM, or XP, or even stealing requirements from existing products -- we achieved a subtle balance that, in our context, allowed us to become winners.

You know you're a winner when they take you out to Smith & Wollensky's and tell you that you can have whatever you want. I think this time the tab was only 800 dollars. And that was just dinner ;-) ;-).

In our case, unless we were 100% whacko (which is perhaps more common that we think ;-), utilizing only part of what XP contains was what allowed us to succeed. So instead of achieving 100% XP, we achieved 100% success by using part of XP. What gives ... or at least, what more could we have done?

-- PhilipEskelin

Just checking one thing, Philip: There were only two of you on the project? Or two doing architecture and 10 doing programming? -- AlistairCockburn

p.s. two or three people solving a hard problem is known as a SWAT team project. It runs with different rules than other projects.

At first there were two of us doing the architecture, design, and development. Part-way through development another person joined our team. As I am now phasing off of it, he is phasing onto it. Everybody likes what we are doing, so nobody has a problem with it.

Is there a problem with that?

Personally, I am against teams greater than five people. Even five starts getting too crowded. But can you rightfully disqualify our development effort as lacking XP because of this? I hope XP is scalable. We used parts of it, and I think it helped us succeed.

In retrospect, even though we were only a small team, I wonder how much more value a model of 100 percent XP would have given us, since we were already entirely successful anyway (by using a part of it). So whether it's 1 or 2 or 3 or 4 or 100 (spare me from that) people assigned to a project, do you think that 100% XP would pay off in a way that you'd be able to sell it to my superiors?

XP as a philosophy towards successful project development needs to be versatile and flexible and valuable. If it's not, it's just another thing on Kent's resume (or at least a great course study of what made the second version of the Chrysler Comprehensive Compansation project a success). Unofficially, what you guys have done has helped me.

Just a guy in the field trying to do stuff, -- PhilipEskelin

Philip, that is a great story. But from the point of view of someone trying to understand software better, you are trying too hard to defend yourself and not giving any details of what you did. What parts of XP did you use? For the parts that you didn't use, did you have good reason not to, or did you just fear pressure from people if you did? Maybe your project would have gone even better if you had used XP. I'm not saying it would, but you don't provide any clues about what really happened.

It sounds to me like you did a fair bit of up-front design. Why do you think that was the right thing in this situation? What other things did you differently, and why?

There are two different kinds of reasons to deviate from a methodology. One is practical; you have to learn methodologies (like anything else) a piece at a time. You have to teach them that way, too. The other kind of reason is that the methodology just doesn't fit the problem.

If the reason that you didn't use XP is that your teammates wouldn't accept it, then your story won't have a lot of impact on XP. But maybe the reason you didn't use XP is that another way of developing software was better for your project. In that case, talking about your project will help us discover the boundaries of XP.

-- RalphJohnson

Let's see...going down the list:

So that's a description of what we did and didn't use on the ExtremeProgrammingRoadmap. If there's another master list I missed, then that further supports my claim that we only used part of XP, and that it made us a little more successful.

Heck, as a city slicker who writes code for a bank, I like all that Listen, Code, Test, Refactor stuff. But one thing that doesn't seem to get addressed directly is risk management. One of the critical factors that led to our success is that we had a special kind of leverage over a 3rd-party dependency that helped us drastically mitigate risk.

One of the folks in our bank had a pen right next to the signature line of a seven-figure check made out to the vendor, but wouldn't sign until all issues were resolved. The sales guy kept showing up to make sure we were happy and that all issues were resolved, the CTO came, the lead developer flew out and they took us out to dinner, and our satisfaction was their highest priority.

In this case, our system would be deployed to thousands of people globally who deal with billions upon billions of dollars on a daily basis. Without this kind of leverage, our code would have been far less stable and it's possible that we wouldn't have been able to deploy it into the production environment. So some kind of XP-style risk mitigation would be cool to see.

Based on the above response to Ralph's questions, I hope this gives everyone a better feel for what we did. I don't know the answer to whether their were good reasons for not using something, or whether it was because of simply ignorance. It wasn't so much that my teammates wouldn't accept XP, it was just that we had to balance what we used and didn't use and name/associate them so our team was comfortable with it.

-- PhilipEskelin

That summarises what Objective has been seeking to do since 1986 - using the GilbMeasurabilityPrinciple to balance value and risk in the context to the strongest possible commitment to EvolutionaryDelivery.

We've learnt a lot from XP that we are very grateful for and we take the ExtremePop on faith even we haven't fully experienced it in a ten person team yet. But something has felt out of balance in the debate so far. Thanks for raising a risk issue that is very typical of commercial development as we know it and doing so very graphically.

See ImpactModelling for a brief introduction to our approach.

-- RichardDrake

Yes, that is a good story! In my opinion, your non-use of CrcCards is not an issue, because you had another lightweight design technique. ModelFirst is not a core part of XP. But I think you would have done better if you had had automated tests. I think all software projects, regardless of size, should have a test suite. You don't have to spend a lot of time on a TestFramework?. You'll spend a lot of time writing tests, but you'll be repaid in full, especially if you want to refactor. -- RalphJohnson

I'd like to introduce another metaphor that seems apt. Juggling.

Unlike XP, juggling has only two practices: throwing and catching. Once you learn it, it's the simplest and most natural thing in the world. But at first the balls will drop on the floor.

Throwing without catching. Catching without throwing. Okay, those are easy to understand. But even after you learn to throw and catch, the patterns aren't stable. They tip over forward and you have to run after them. They're lost with distractions, or unfamiliar balls, or fatigue. And the favoured hand can do tricks the unfavoured one spends months learning.

Eventually, sure, you can juggle. But then you try to juggle one more ball ... and the whole thing has to be learned all over again.

Now with XP, based on my experience of trying to introduce it over the last six months, this is also true. The first pattern I tried to get stable was the PlanningGame. After several fumbles, that's now easy for my group to do. Then we did CRC. Okay, that's stable now too. The next two I'm trying to get to happen are PairProgramming and ContinuousTesting. Then I'm hoping I can toss in RefactorMercilessly.

Does it make a difference to the PlanningGame or CRC that I haven't got the other three stable yet? No, it doesn't. I see, imho, a vast benefit from PlanningGame and CRC alone. If I can get ContinuousTesting to happen without pairing or refactoring, again that'll be a vast benefit. It is true that refactoring requires ContinuousTesting, but the reverse isn't true. And if I get those three and still can't get up pairing, well, that's still going to make for a much healthier development than otherwise.

So my thought is that adopting each XP practice is a new struggle that has to provide benefit in its own right. I don't think XP practices are truly interdependent; I think some depend on others. A FiveBallCascade? requires you to have stabilized a ThreeBallShower? in both directions, a FourBallCascade?, and a ThreeBallFlash?. ThreeBallFlash? requires you to have stabilized the basic ThreeBallCascade? ... obviously you start with that and then work up.

So I think it's counterproductive to say you have to use a large amount of XP before you get much benefit from it. I think you can get benefit from each part in isolation, and that the whole can be adopted by easy stages without too much forethought.

-- PeterMerel

Yes, it would be incorrect to say that you have to use a large amount of XP before you get much benefit. That's why we don't say it. Instead, we say that each practice has benefit; we say that some practices support each other and are much more difficult alone (e.g. RefactorMercilessly really needs the support of UnitTests); we say that doing all the practices seems to "pop", delivering disproportionately more benefit. --RonJeffries

Okay, but again I'm reminded of juggling. When you try to learn a new pattern you usually first get it in an unstable way. It requires great effort to maintain it for even a few seconds ... and then the balls drop. But one day it "pops", and then it becomes both effortless and unconscious. You can speed it up; you can do it while concentrating on other things; you can rely on it working, even when what you're juggling is eggs, flaming torches, or chainsaws.

Then again if I could juggle chainsaws would I be doing this for a living? Perhaps that would qualify as ExtremeJuggling? :-)

-- pete

Part of what I'm trying to get at is that I'm currently using a subset and getting value out of it, similar to how I get value out of using a subset of the interfaces provided by COM. I don't think anybody's downplaying it. But I'm also trying to understand how that extra 10% makes something go from successful to magically successful. All along I've been thinking about A Pattern Language and how you use a subset of the pattern language to generate your own. -- Phil

From where I sit, a key element of Philip's story was that there were only 2-3 people. I think "what you can get away with" are different for 2-3 people than for 6-8 people than for 10-14 people. "What you can get away with" is a euphemism. With 2-3 very good people, there are almost certainly variants on a theme that work about as well as the theme, and they may be working at close to optimum using any of a variety of combinations. As the number of people goes up, the space changes. At 8 people, you (first of all) aren't going to have the same caliber of people. Even if you did, their communication would get in the way, so there would be additional artifacts in the working relationships.

It may be that the "popping" Kent refers to, is getting 6-12 people to work at similar efficiencies to what 2-3 people like Philip can get. Philip and his colleague can invent a couple of different, essentially equally efficient mechanisms for themselves, and they can sense on the fly if they can do better. Doing large overlaps with XP will get them there. This is my best current guess.

-- AlistairCockburn

You're probably right. I kept thinking 2-3 people, 2-3 people, etc as I wrote down what we did/didn't use. We had an executive sponsor, a part-time project manager to handle infrastructure issues, a part-time data services resource, and us two builders (until our third came on board). Bigger projects at 6 or 8 people definitely get more complicated to manage, and perhaps this "pop" is more important and/or has more of a discernible effect.

A project I was on in 1997 and 1998 had 5 people. We had 2 really good people, we had 2 people who were good without much experience on our development platform, and one very junior person. We did some of the XP practices (not all of them) and experienced success. I might be on a roll ;-) with all these wins but in each one of them we only used a part of XP.

-- PhilipEskelin

You've had two important business successes and you've benefited increasingly from the insights of XP in the process. Your focus was not on optimising the process to the degree that some are interested in around here but (at least I have often felt this way) optimising just enough within existing resource, social and political constraints to achieve business success. That is true professionalism. It's not easy. I salute your achievement.

I agree about the points about team size (and with most else from Cockburn I have to admit). What interests me and I guess a lot of others around here is that just maybe with XP in 'fish tank popping mode' (if it's remarkably stable once it's popped than it's not strictly 100% XP and I would drop the 100 for good) TeamsOfUpToTwelve say could achieve certain kinds of business goals that would simply be impossible any other way. They don't like to boast about it (huh?) but maybe that's what the C3 team are trying to say. They simply wouldn't have made it to business success without the 'pop'. Or maybe there were other factors at play too ... see ChryslerSuccessDueToPopping? some time soon.

-- RichardDrake

Hmm, shucks, thanks for the compliments. For me it all comes down to this: I like XP as a tool and nothing more. XP is like a Swiss Army Knife -- one guy may use it merely to cut open boxes, and another might floss his teeth, fix leaking dams, file his toenails, and carve wooden figures with it -- each person utilizes it as a tool to fit their own situation.

And perhaps this popping thing is not so much something that needs to happen for XP projects to be successful with 6-8 people or more, but instead is a critical success factor for any project of that size.

-- PhilipEskelin

WellFleet?, my project before C3, didn't (and doesn't) use all of XP. They also have 2.5 people on the project. They are happy and successful and see no reason to invest in changing. So I tend to agree with Philip in the sense that you should do everything you need to do to be successful.

To complete the experiment, Philip, you would try unit testing on your next project. If it didn't add anything, XP is a menu from which you can pick. If the project went significantly better, then the TwentyEightyRule is in effect.

The 20/80 rule as applied to XP is a hypothesis. I'm sure not all 10 or so practices will be in the core group when we're done. But I believe the effect is there, and I can't think of which of the core group to throw out. Now we must experiment.

-- KentBeck

Refactoring Discussion

What WikiName would you propose changing to?

It's a fine name for the first section. After that...I make some suggestions below but I lack time and my WikiMaster badge.

I wasn't really paying attention to the name when I participated in that discussion.

Everybody does it. It was a great contribution. But .. what now?

It would be a sexier concept if it was labeled ExtremeSomething? or similar.

-- PhilipEskelin

ExtremeNonlinearity? would make sense.

ExtremePop might be cool too.

Does anyone agree that it would be worth refactoring along the following lines:

-- RichardDrake (the man without the WikiMaster badge)

There are no WikiMaster badges, Richard. There's only us chickens here.

As MartinFowler stated in ReFactoring, refactorings should be done one at a time. I once did a big refactor on TheSourceCodeIsTheDesign, and it really hurt. I suggest you take a single big piece (say, Phil's Smith & Wollensky story), refactor it out, and then let things sit for a day or two, and then see what would be the next logical thing to refactor out. -- BillTrost

CategoryExtremeProgramming CategoryAdoptingXp

EditText of this page (last edited December 27, 2011) or FindPage with title or text search