Extreme Values

I notice "the ExtremeValues" on this page [AreYouDoingXp?] are not identical to the ones on the ExtremeProgramming page. Aggression replaces Coding. Is this difference worth elaborating on? -- DaveHarris

The difference is between the activities vital to the development of software:

and the values shared by the team doing those activities: I have always preferred Fearlessness, which hearkens back to (I think it was) Alistair's comment about typical methodologies being born out of fear. Any comments on the differences among CourageAggressivenessAndFearlessness) -- BillBarnett

The activities are what you do. The values are how you decide if you are doing it right. Does that answer your question? -- KentBeck

So how come Testing is both an activity and a value? Or, as a value, does it mean testing the methodology? And, if so, could this refer to <shudder> the MetaExtremeWay? -- PeterMerel

I've been thinking about changing the third value to "Concrete Feedback" or just "Feedback". This happens all the time- "have you coded it both ways?", "have you carded it with the customer?". It also happens at all scales, from a pair writing unit tests so they get concrete feedback about their progress to putting a small system into production as quickly as possible so the business gets concrete feedback about what is and isn't valuable about their vision. Would "Concrete Feedback" be better? Which form, one word or two? -- KentBeck

Isn't this the same as communication? -- MichaelFeathers

The two are hardly synonymous. Feedback isn't just information flow. It's information flow in response to action. -- KielHodges

I like it! Feedback-driven activities are apparent throughout XP. It's clearly critical to XP (and any other iterative approach). Naming it as a value recognizes its importance and makes explicit a facet of the philosophy that goes beyond testing. (Listen to the code!)

To me, the one-word form fits the 'style' better. -- KielHodges

I also like 'feedback' better as a value, as it captures not only testing, but nanoincrements and other practices (including, at a stretch, pair programming). -- AlistairCockburn

I like Feedback as a value also, because testing is a special case of feedback. I'm tempted to add "Concrete" because I've seen people review CirclesAndArrows? with customers and think that constituted feedback (along with various other forms of abstract feedback). But I also like the one word rhythm. -- KentBeck

As always, Kent, you've said what I was thinking better than I could say it: Feedback fits the rhythm.

I'm not (very) concerned about the potential misunderstanding. Communication, Simplicity and Aggressiveness could also be misunderstood. They work on a mnemonic level, but require further elaboration. (I've seen a lot of projects that misunderstood Communication!) I like the idea of something catchy. -- KielHodges

Yes, I like this too - "Feedback". On the difference vs Communication: Communication means you want to encourage awareness of the whole process by everyone concerned. Feedback refers to control - it means each part of your process is directly and frequently influenced by the reactions of the consumers of its deliverables. -- PeterMerel

Would "Visibility" be a better term for communication given the distinction Peter makes? -- WardCunningham

Would "Control" be a better term for feedback, also based on Peter's distinction? -- WaldenMathews

"Communication" seems to me to be more proactive. -- RonJeffries

FeedbackIsControl.

I think Testing/Feedback can be regarded as forms of communication, with the code rather than with a person. So is ContinuousIntegration IMHO (actually that one is both at once, and so is PairProgramming). Or perhaps I should describe ContinuousIntegration as communicating through the code whereas Testing is communicating with the code (and PairProgramming does both at once).

What I think is explicit in much of XP but not easily apparent in the values as expressed here is the notion of High-Frequency! It's not just communication that's important to XP, its ultra-high-frequency communication (with people & code)! That's why the integration is "seemingly continuous" because its done in a matter of hours or minutes instead of days or weeks. The same is true for the frequency of running unit-tests. And PairProgramming is like a two-person continuous code-review in many ways.

Why is this? In order to truly EmbraceChange, you dont just face it head on, you run right to it (embracefully ;-) and start tackling it as soon as each little wisp wafts in through the crack of the door. You cant simply be reactive, you must be proactive!

IMHO the most extreme thing in XP is the frequency with which these various forms of communication are proactively practiced, both with code, and people (developers and customers). The frequency is so high as to make it seem continuous where possible. So no matter how big the change you are embracing, you address it instantaneously and wrap-it-up quickly in small manageable chunks that feed right back into the stream of change, with minimal disturbance and maximal adaptivity and proactivity.

Hence XP embraces change continuously! That it doesn't hesitate to refactor (e.g. CollectiveCodeOwnership), or reformulate can seem like "courage" or "aggressiveness". And sound, sensible practices like formal reviews don't make sense in XP because the implicit assumption of discreteness no longer holds. Its just too large-grained to fit into the flow when you EmbraceChangeContinuously.

In this light the aforementioned four values of XP boil down to the simple pair of "Communication" and "Simplicity." In order to get the most effective communication we need to be concerned with the quantity of communication and the quality of communication. ContinuousCommunication address the issue of "quantity" by using ultra-high-frequency communication of very small and manageable chunks. ContinuousSimplicity addresses the issue of "quality", optimizing the signal-to-noise ratio through things like RefactorMercilessly and DoTheSimplestThingThatCouldPossiblyWork and TheSourceCodeIsTheDesign.

To me at least, these values are the essence of how XP successfully embraces change, via the proactively continuous application of both communication and simplicity in all aspects of the project: the code, the developers, the customers, and the management. The ExtremePrinciples of ExtremeFrequency and ExtremeProactivity are constantly and consistently applied to these ExtremeValues to effect ContinuousCommunication and ContinuousSimplicity throughout all of XP. -- BradAppleton

I don't find simplifying the values to less than the above 4 to be helpful in regards to codifying a set of hooks upon which XP hangs. I'm sure someone could explain the above 4 values in terms of one word (Action?), but that seems to me like trying to derive everything from first principles...nice if you are a theorist, but a little low on the pragmatism food chain. For that reason I like the idea of explicitly mentioning feedback and aggressiveness separately.

Definitely! I didn't mean to suggest otherwise - merely pointing out some more fundamental factors/principles IMHO, as opposed to redefining the values. For me at least, those get to the core of the matter, and make it all make sense (for me ;-)

I feel that by putting the word continuous before each value, or prefacing the group as a whole with continuous, you get across the idea of high frequency along with the values. It seems important to emphasize that high-frequency aspect of XP practices, because they all seem to relate to it. In that sense, I agree with Brad's comments

-- RonGarcia

The word "continuous" gives me pause. (*cough*) "Continuous" means "without pause or interruption." E.g., you must breathe continuously or you die. It implies a major commitment to doing the same thing endlessly.

I think a far better term is "continuing" or "ongoing." You avoid the idea that you can walk away from finished code, but you don't leave the reader wondering if XP means that you must review code on a schedule dictated by the calendar. A comment I saw elsewhere really nailed this for me - the author described how he'll touch a file once without thought, twice with some concern, and refactor it on the third. That's a good example of a "continuing" process. A continuous process would require you to refactor every time you touch a file.

-- Bear Giles <mailto:bgiles@coyotesong.com>

Are the ThreeVirtuesOfaProgrammer ExtremeValues or better: how can they be integrated into the XpValueFrameWork?? -- FridemarPache

CategoryExtremeProgramming

EditText of this page (last edited November 11, 2005) or FindPage with title or text search