Extreme Programming In Context

As we've described elsewhere, ExtremeProgramming rests on the values of Simplicity, Communication, Feedback, and Aggressiveness. Some of our key practices, taken out of context, can raise eyebrows. Here's some context for some of the tricky ones.

We all follow the exact same CodingConventions. We strive to name methods the same way; we even format our code the same way. This makes for better communication between programmers. It also helps us go faster (aggressiveness) because it is easier to see quickly what the code is doing.

When we see a need for MethodCommenting, we turn first to improving the code. When we see a method that isn't clear, we don't take the luxury of putting a comment in "to make it clearer". Our first recourse is to fix the code so that it is clearer. This generally means making it more simple. The system is easier to understand, improving communication. We do use comments for situations where the code alone truly cannot communicate everything that's needed.

We practice CollectiveCodeOwnership, rather than individual CodeOwnership. This improves communication by getting things done immediately that would otherwise require negotiation with a class owner. It is part of aggressiveness, letting us move quickly wherever Smalltalk tells us to go.

We use FrequentReleases, each developer releasing code once a day or more often. This is made possible by our many UnitTests and FunctionalTests (testing). The practice reduces integration time, improves communication because we stay in sync, and is a key part of aggressiveness.

We avoid excessive investment of time and code in future possible needs, by assuming YouArentGonnaNeedIt. This practice keeps the code simple. By reducing the volume of what we have to look at, it improves communication. Again, it feeds into aggressiveness.

Although we attack the most risky (least understood) parts of the system first, we DoTheSimplestThingThatCouldPossiblyWork. This keeps the system simple. It lets us understand the essence of the problem, improving communication on the solution. We back the simple solution with loads of testing, ensuring that though it is simple, it is robust.

We practice PairProgramming. This improves communication. It also results in code that is more simple, since two heads are better. And it increases the focus on testing (and all our other values) since we find that we are all a bit more careful to follow the rules when people are watching.

We write the ModelFirst, then follow with a SpartanUserInterface. This allows us to focus our skills in high-risk, high-value activities.

ExtremeProgramming is a system of ideas that work in concert to produce good programs quickly. The rules need to be used in context, and to be used wisely in support of the values. -- RonJeffries

This isn't "context" in the sense of patterns, is it? It's more working through the consequences of the principles and emphasizes on the ExtremeProgramming page: what extreme programming means in practice. As part of the process of reconciling your theory with my own experience, I'm interested in exploring the external contexts in which XP would work.

For example, in ToNeedComments, RonJeffries says, "No question, XP is very much about ProgrammingInTheSmall?." The SpartanUserInterface pages talk about when that pattern is inappropriate - when the UI is a high risk part of the design. I suspect that XP as described here works best in Smalltalk and would need to be modified for C++ or Java. -- DaveHarris

Everything works best in Smalltalk. ;-> Seriously, we do rely on Smalltalk's dynamic nature to support what we do. We'd still focus on our values (simplicity, communication, testing, aggressiveness), and would prefer code clarity to comment, focus on the now, and so on. With refactoring harder, we might need more planning. We'd let the values drive us, and add "overhead" only where we had to. -- RonJeffries

I don't think XP needs to be modified to work in other languages. Using Perl, our team has had no changes needed to make XP work very well for us. In fact, it is a major needed improvement in methodology for a language that is prone to poor programming practices. -- JeffBay

Where in this Wiki could one find the connection between XP and an organization's IT architecture (the deployment context)? No matter how efficient an proposed XP effort might be, if the target architecture is near collapse or fossilized the new effort may be a waste. Are there success stories where an XPer helped RefactorMercilessly a client's IT infrastructure? -- SteveLu
I should like to explore what you are calling ProgrammingInTheSmall? in the context of XP. I don't see it as that, nor do the dozen(s) of people who didn't manage to deliver Chrysler payroll not doing XP. So you must have a different interpretation either of XP or ProgrammingInTheSmall?. Please clarify? -- AlistairCockburn

I've made the attribution more precise above. I apologize if I mis-used the term. If we distinguish 3 scales:

Then I was thinking of the middle scale as opposed to the last. What I'm really interested in is, where XP conflicts with conventional wisdom, how much of that is because conventional wisdom is wrong and how much because it was devised for a different context? -- DaveHarris

XP has not been tried in larger groups. We believe that the values will surely apply, and that many of the practices will survive. We have no proof. -- RonJeffries

Some aspects of the philosophy remind me of bee hives or Borg (pre-leader variety). Sounds enjoyable and effective with the right group. -- WayneCarson

It is both. You will' be assimilated. -- RonJeffries

I get the impression XP is designed for developing new software (what JimCoplien calls "greenfield development"). It may be hard (it may be impossible!) to develop UnitTests for testing modules in isolation, if such modules were never meant to be run in isolation.

I suppose in principle this is possible. It is can be difficult writing unit tests for large volumes of existing code, but altering unknown code without tests is even more difficult. In an object system, even one that isn't very good, there should be enough independence of classes to write decent tests. And it's perfectly OK for a class to use its collaborators to accomplish its work - that's an inherent part of object-orientation. -- RonJeffries

I've taken an existing project and started to write UnitTests for it (see ExtremeReuse). It is an opportunity. When you start to pull individual classes out for testing, you see refactoring opportunities. In addition, the act of pulling out a class and seeing what else you need to make a fixture places dependencies in stark relief. More opportunities for refactoring. Whenever I have a chance, I try to take a piece of the code and do this. I don't think I'll ever finish in this project, but the gradual morphing of the software should be advantageous.

I suspect that there are many opportunities for refactoring in any code base that has not been consistently refactored. Thinking about how to write a unit test helps you find them.

-- MichaelFeathers

Kent Beck learns systems by refactoring as he goes. It's fascinating to watch him pick up the web at a random point and quickly build understanding. I'm just an egg, it's a lot harder for me. (Unfortunately, I'm a very OLD egg.) -- RonJeffries

Ron, speaking of learning, how much did you and Kent discover/clarify about ExtremeProgramming by attempting to summarize it here on Wiki? Did you thrash out the patterns here, or did you write a paper or something first? -- StanSilver
We thrashed it out by doing it. The C3 project was the first place where XP was in place as a process, with attention to the rules, what was and wasn't working, etc. We modified and tuned a lot during the C3 development - and we continue to learn. Kent has also learned a lot during his time in Europe, though he hasn't yet turned that over to me in a form I can use ... other than to stay out of Switzerland until I get a bit more inclined to follow rules. ;->

It's been said that in Switzerland, everything that isn't illegal is mandatory. -- Anon. I can't comment on that because there isn't a rule that says I can.

Having lived in Switzerland for 18 years, I still haven't designed the test cases to prove or refute this. -- JosephPelrine

We have learned a lot about expressing what XP is by writing about it here, but we learned what it is on C3. -- RonJeffries

The roots of XP go much further back, of course. I'm just trying to achieve for myself a pale imitation of what Ward does naturally, and teach others. -- KentBeck.

EditText of this page (last edited December 13, 2004)
FindPage by browsing or searching

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006