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
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
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 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:email@example.com>
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006