Core Xp Dependencies

Perhaps this page might be more correctly named Core XP Relationships, as it appears most of what is shown and discussed are not true dependencies, i.e. A cannot be done without B.

This is one of the cases where a picture may be worth if not 1000, then a LOT of words. A lot of us are visually oriented. Therefore when we are trying to understand how concepts relate, the best way to do so is with a picture. So here it is:

(Here is another diagram on the same subject: ExtremeProgrammingEnablingChart)

What the boxes represent are the core XP practices as I see 'em. The arrows are dependencies, meaning "don't try to do this without doing the thing on the other end of the arrow". For instance, DON'T do refactoring without unit tests.

Some dependencies not yet labeled on the above graph:

ContinuousIntegration---> CollectiveCodeOwnership -- If a project practices code ownership then developers will be sorely tempted to keep code "checked out" for long periods of time while they slog through defect lists or feature requests from other programmers. If your developers tend to keep code "checked out" for long periods of time, then you can't do ContinuousIntegration. If anyone can make any change, then continuous integration becomes a possibility... (What say you wikizens?)

This one seems to be a bit of a stretch. Maybe there isn't a relationship for this one.

MercilessRefactoring --> ContinuousIntegration - Refactoring leads to version control conflicts without continuous integration.

I'll almost buy this one. But consider the following scenario. What if you're faced by someone who follows a full ClassOwnership model where each person maintains all their own classes? They can refactor all they want, but as long as the behavior (and interfaces) don't change, they don't screw up anyone else. That wouldn't require ContinuousIntegration. Practically, of course, we know that the interfaces would have to change, but this is the kind of theoretical possibility that people will drone on about...

Except that a ClassOwnership model is hardly compatible with MercilessRefactoring

Why? Please provide some simple reasons here.

Many important ReFactorings? involve moving things between classes. You can't do that if you don't own the class. MercilessRefactoring implies OnceAndOnlyOnce. You can't do that if you can't do cross-class refactorings.

Interestingly enough, this also highlights another dependency:

MercilessRefactoring --> CollectiveCodeOwnership
SmallReleases --> SimpleDesign

Please give some reasoning as to why SmallReleases depend on SimpleDesign. For instance, why can't you do a SmallRelease? of a complex design?

Because you can only do so many things before a small release turns into a large release.

Explanations of dependencies already labeled:

CollectiveCodeOwnership --> PairProgramming, StandUpMeeting, MovePeopleAround - Every developer needs to know enough about each part of the code to make CollectiveCodeOwnership a good policy.

I haven't included MovePeopleAround since it's a cardinal practice of PairProgramming. I might include StandUpMeeting, but I'm not sure that it's really a core practice - I've seen it used and still seen projects fail, but I've seen successful XP projects where people sit down at meetings...

CollectiveCodeOwnership --> CodingStandards. Without CodingStandards, CollectiveCodeOwnership is impeded because you will spend too much time puzzling out unfamiliar coding styles and naming conventions.
CollectiveCodeOwnership --> UnitTesting and AcceptanceTests to be in place. If I am allowed to change code I didn't write, how can I be sure it still does what it is supposed to? How can I be sure my changes don't break a third party's code? XP's answer to that is UnitTesting: The tests tell you if the code still does what it's supposed to, and if they succeed but some other code breaks, there is a test missing. Actually, I believe many XP skeptics are not aware of this dependency and argue against Collective Code Ownership while ignoring Unit Tests. There has been some discussion on other wiki pages that in XP FunctionalTests == AcceptanceTests. AcceptanceTest is the officially accepted nomenclature. A correction of a misunderstanding of this can be found at CanFunctionalTestsReplaceUnitTests.
Simple UserStories --> OnSiteCustomer -- You don't have stories without customers. If the customer isn't around constantly, you won't be getting new stories. Also, the customer will be needed to to fill in the (intentionally missing) details from the story cards.
MercilessRefactoring --> UnitTesting - Without unit tests, you won't know if you're breaking something.
UnitTesting --> ContinuousIntegration - If you're not doing ContinuousIntegration, then you'll never be certain that your UnitTests really work. You have to have a single code-base moving forward because if you don't the UnitTests will diverge -- losing their value.
PlanningGame --> "Just-in-time Analysis (UserStories)" - The PlanningGame requires UserStories (or the equivalent) because the unit of debate in the PlanningGame is the UserStory.
RapidDesign (CRC) --> "Just-in-time Analysis (UserStories)" - This comes down to the fact that you can't do design without analysis, and that simple analysis focused on enumerating one problem at a time (e.g. UserStories) lead to simple, fast designs that solve one problem at a time.
RapidDesign --> SimpleDesign. You can't build a complex design in a short time. The only reason you can get away with doing very short design cycles is that you only design (relatively) simple things that can be easily time-bounded.
RapidDesign --> SmallReleases. You can't do a quick design for a big release. (Or does this make more sense the other way around?)
SimpleDesign --> Refactoring. The only reason you can DoTheSimplestThingThatCouldPossiblyWork is that you know you can always refactor it later if the problem turns out more complicated than it seems. For more information see WhatRefactoringMeansDiscussion

It bothers me that PairProgramming is off by itself. Maybe nothing depends on it directly, but in my experience, it is the thing that makes teams blossom. It is the turbo-charger. -- MichaelFeathers

What about SystemMetaphor and CodingStandards? What are the dependencies there?

Perhaps there should be an arrow to SystemMetaphor from CollectiveCodeOwnership? If people are going to be passing code around to each other, they'd better have some sense of the overall picture. -- MikeSmith

I would suggest showing UnitTests as being supported by AcceptanceTests (I am not sure of what the arrow convention is here). AcceptanceTests fill in the gaps left by UnitTests. -- WayneMack

The arrow convention (as explained above) X->Y (read as X depends on Y) means you can't do X without Y (e.g. doing X without Y is a really bad idea. For instance, you can't do Refactoring without UnitTests.

Michael's comment gets to the heart of my problem. It seems to me that XP is in fact not all or nothing. There are at least two groups of practices that might be more-or-less independent. Now, I'm asking for the following things:

(1) Can anyone explain why any of the rest of the XP practices depend on PairProgramming. Not that I don't believe that PairProgramming is a good thing - in and of its own it's a wonderful thing as LaurieWilliams has shown in her studies. But what else in XP relies on PairProgramming and won't work without it?

None depend in the sense of live or die. Many are strongly aided.

How are they strongly aided? Give me some simple statements that will indicate how pair programming aids the others. I'm looking for the logical principles that say if you do X then Y will be better BECAUSE...

'Just one of dozens of reasons is that Developers will tend to do less and less testing if no one is watching'

(2) There's a set of connected practices around UserStories that XP shares with the old JAD (Joint Application Design) sessions. XP has its own spin on it, but the idea of very short, customer-focused iterations doesn't seem to rely on any of the other practices - JAD sessions worked well without the other practices.

AFAIK, JAD iterations aren't as short as XP's, but there's nothing wrong with JAD. The programming practices of XP just make short iterations better.

Guys, I don't want to cause a religious war here (hard when you talk about XP) but I'm really looking for some hard, solid reasoning as to why you can't separate pieces out and have them still be useful...

You can. Some subsets are quite useful. Some rather obviously don't work. All together work particularly well.

(DierkKoenig) I strongly support Hasko's point. (CollectiveCodeOwnership -> UnitTesting -- hh) And I would add: Why is TestFirstDesign missing in the picture? For me personally it is a core practice with some strong dependencies:

: TestFirstDesign gives the focus for PairProgramming sessions
: TestFirstDesign eases UnitTesting dramatically
: TestFirstDesign leads to SimpleDesign

UnitTests are the XP implementation of TestFirstDesign.

(DierkKoenig) OK, you're right. UnitTest includes CodeUnitTestFirst. But the name doesn't reveal it. I've seen a lot of UnitTests written afterwards (about 80%, actually). So there seems to be a difference at least in the perception of the programmers. The do not expect it to be so much of a difference.

This chart includes most of the dependencies mentioned here and lots of other 'weaker' dependencies that are also likely to exist. -- JonGrover

As of December 2004 both charts vanished, and they are not in the WaybackMachine either :-( does anyone have a backup?

See CoreXpDependenciesDiscussion, XpCodingDependencies and UsefulXpSubsets

CategoryExtremeProgramming