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
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
I've made the attribution more precise above. I apologize if I mis-used the term. If we distinguish 3 scales:
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
It is both. You will' be assimilated. -- RonJeffries
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 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.
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
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.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006