Wiki Home

Extreme Programming

Namespace: WIN_COM_API
A good Agile/XP resource: Joe Kuhn
I read this really cool article on pair programming. Sounds like it's a great idea.

Available for download at no cost from IEEE Software Mag.
--Daniel Johnson
I have some questions about what I saw at (besides, "Are there really customers who will pay for a pair of programmers at each workstation?" )

Charles Hankey and I use Pair Programming whenever we get the chance. When we're able to get together and work like that we are easily twice as productive vs. when we're both working alone. We don't do it on-site and have never explicitly told the client we use this practice, but they've always been pleased with the results and never questioned the bill. We also use Pair Programming a lot when we mentor people on our framework and the results have always been good. -- Mike Feltman

First, don't optimize until you're done coding? In the client-server world, you could find yourself in big trouble if you haven't done at least a little testing on access methods, etc.

Also, I understand "never add functionality early". But the page dealing with that tenet goes further: "Turn a blind eye towards future requirements and extra flexibility. Concentrate on what is scheduled for today only." Does this really work in a complex project? - Zahid Ali
I'm just now getting my head around XP, but I'd think that this concept should work just fine, as long as you follow the XP principle of Merciless Refactoring. If you follow this practice, adding additional functionality should be much easier. Another way of looking at it, is what is the difference between adding functionality only when it's needed for this iteration, an some functionality that gets added down-the-road when the client says, "Oh, by the way, we forgot to tell you about this".

Another thought occurred to me on the way to GLGDW (to do a session on Refactoring) - While the XP stricture is to not code for re-use, I think that Merciless Refactoring could often lead to serendipitous opportunities for re-use; when, in the course of refactoring you abstract functionality in a superclass, (so that it can be shared between two or more subclasses) there is always the possibility that the abstract behavior could be specialized in some new class that wasn't anticipated at the time of the original refactoring. To actually re-use this superclass may require a little more re-factoring, but as long as you have good test cases to ensure that the original classes in the heirarchy aren't broken in the process, you'd be foolish to not employ some re-use when it's handed to you. Steve Sawyer
There are those on the Extreme Programming mailing list that can answer these a lot better than I, but here goes:
1) One programmer signs up for a task, and then gets a partner for that task. This may sound like the velocity is 50% of what they could do separately, but the experiences of those using pair programming is that in fact the pairs produce MORE than what they could individually. There are supposedly studies to that effect. (check out the XP sites for them).
2) read the sections on Unit Testing, and TestFirstProgramming (at the Wiki Wiki Web for more depth--see the links further down this page). XP shops build automated UnitTest frameworks, and no code gets committed until all tests pass 100%. Further, tests are written before the code, so this serves to minimize the issues you mentioned. Finally, integration is daily, so you know right away that your changes are good or not good. If the tests fail, you know your new code broke them, because all code integrations must pass 100% or be rolled back.
3)YAGNI(You aren't going to need it) is the idea that when you design for future functionality, you are gambling that the feature will actually be implemented. Highly componentized, and unittested code can handle this high rate of change. RefactorMercilessly is the XP mechanism that lends itself to late iteration requirements changes. Also, each User Story is envisioned quasi-independently, and so can be modified any time before they are actually implemented.

In short, it is a mistake to look at XP in pieces--the various practices reinforce each other, and the strengths of one compensate for weakness of others.

I highly recommend Kent Beck's Book: "eXtreme Programming explained" if you would like a more complete coverage of these ideas. Also the list archives (and the mailing list itself) addresses these kinds of questions almost daily. -- Bill Caputo
We use xp at my company and it has had a profound impact on our ability to meet customer requirements. Using the XP techniques of story meetings, estimates, value, test first, and pair programming in short, focused iterations, we are able, with a relatively small development team, to release regular, predictable, and valued updates to our applications.

We're currently developing new versions of our five Windows clients and a server product for Windows and six flavors of UNIX.There is no way we could be actively all of these products at a company of our size without XP.

Kent Beck's book is definately a good summary. Rusty
XP is a process that involves heavy customer communication, lots of planning, high level modeling, a dedication to design and architecture, and a desire to develop with a minimum of overhead.

Extreme Programming started as an ad-hoc collection of prescriptive approaches based on experience and common sense, and has evolved into a bona-fide software development process.-- Steven Black
A deep (deep!) topic on the Wiki Wiki Web at and, possibly a better starting point, at
Just curious if anyone here uses this process? Care to share some of your experiences with it?

Yes. I am an adherent of XP. It does work if one is good at prototyping and has strong analytical skills. The trick to XP is knowing that you will be Refactoring your code and drilling-down in data detail and app functionality as your customers get more involved with the project. -- John Koziol

I read (some of) the Web resources, Kent Beck 's book eXtreme Programming Explained, I am on their mailing list, and I am trying to work the practices into my daily work.

A question for those of you already up and running, what are you using for a VFP Unit testing framework? Did you roll your own, adapt an existing one (I was considering porting the VBUnit framework which in turn is based on the JUnit framework but haven't gotten around to it yet), or are you not using automated UnitTests yet? -- Bill Caputo

Check out Fox Unit -- it's free and open source. -- Russ Swall
I've recently spent some time looking into Extreme Programming and I have to say that I still have my doubts. Well, partially because of personal preference. I'm a strong believer in planning ahead and getting things done right and at a high level of quality rather than going into an endless loop of failing and rewriting until it kinda works. I especially wonder how Extreme Programming will work for complex distributed environments where clients and servers have to communicate through well defined interfaces. Imagine a B2B scenario created by trial and error. Also, what about off-site developers? I assume paired programming could be done through pcAnywhere ;-). But seriously: It seems that the most likely scenarios for teams with off-site developers are small teams up to 10 people and that's exactly what XP is good at. But my knowledge of Extreme Programming is not yet complete enough to form a final opinion. -- MarkusEgger
I am not sure if XP is architecture-centric (Can anybody confirm this?). Most current software development process are. If XP is architecture-centric the idea of refactoring might apply to individual methods (not interfaces) and then I will agree with XP. If the XP idea of refactoring refers to the interfaces between classes then I will agree Markus.
-- Hector Correa
While changing interfaces is a hairy process, adhering to the unit testing principles of XP ensures that you have the courage to move forward without negatively impacting the system. Running all your unit tests (which XP recommends doing each time you check in your code) will instantly show you where changes to interfaces break your code. - dmarlin
The XP principle of merciless refactoring implies that the point is not to modify the interface, but the internal organization of the class(es). I quote from Martin Fowler - "[re-factoring is] the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves it's internal structure". Also, (to correct the impression that Markus may have given), XP is definitely not a "trial-and-error" approach, and it's very strong on design. The difference is that whereas what XP folks refer to as Big Design uses a lot of up-front design, XP allows a more dynamic approach of (in effect) creating working prototypes that are immediately thrown away after being re-factored into a cleanly designed implementation. Thus it really takes a commitment to this process and an ability to resist the temptation to leave the "prototype" as-is and release it because it already works. Steve Sawyer
See :- Nice, simple, fat-free web site. -- Randy P
See Not so fat free
as it was, but still informative. Michael Chean
See proposes a "Manifesto" of principles that are the basis for Extreme Programming, FeatureDrivenDevelopment and other modern methodologies -- Ted Roche
I see (for Fox developers) several obstacles to employing the XP methodology as presented in Kent's book. Anyone interested in adding to or commenting on this topic can jump in at Obstacles To XP. Steve Sawyer

I think a preference for XP or a heavily pre-designed approach is down to the individual's particular mental make-up. I have to be forced at gunpoint to do anything beyond a fairly high level of design to be honest, I would balk at spending days farting around with UML, and I find my customers just wouldn't pay for it anyway. -- Alan Bourke

Category Methodologies
( Topic last updated: 2007.01.12 05:13:55 PM )