Extreme Programming Boundary Conditions

There are so many pages of discussion about ExtremeProgramming that I would like to see a considered discussion of what its boundary conditions are. My hope is that on this page we can set out what we feel must be present for it to be applicable, or what, if present, would make it inapplicable. --AlistairCockburn

So far, I hear/see

less than 15 people total, sitting in one room together
using Smalltalk
single target system (one project)

Also, perhaps

in-house development (one customer)

Request permission to brainstorm a moment. Removal of this section constitutes refusal of permission. --RonJeffries

Against:

death-march management mentality
strongly politicized / polarized customer-developer relationship
prima-donna shop (or leadership)
imposition of all or part of a BIG methodology (e.g. giant CASE tool, huge requirements docs, etc)
staff unwilling / afraid to publish estimates

I would try to use the approach on a non-Smalltalk project. The cycle times for things like "ContinuousIntegration" might have to change; more change control might be called for, etc. But the philosophy, I believe, would hold. Having been (put) through it, I feel that XP is what most top developers are trying to do anyway.

I am interested in doing something like (or adopting part of) Extreme Programming on a Java based enterprise-wide, distributed multi-tier (buzz word alert) project. But, (and I am sure I am missing a BIG POINT about XP here -- so many Wiki pages, so little time) I can only see it working within the confines of pure application programming in a rich development environment (Smalltalk w/ something like Gemstone?)

I have three groups of developers: User Interface (usability, visualization), Biz logic (domain experts) and System (architectural support).

I can't effectively argue why I have the UI group separate from the Biz group: it just felt right--the Biz group is full of people that understand how to code the complex business rules that define the client's finely tuned process and the UI group deals directly with usability issues that the Biz group aren't prepared to address. (Besides, the two groups constantly cross-pollinate and their division is a blur. The User Interface IS the application, the biz logic IS just support code.) I am not convinced that having Biz developers do SpartanUserInterface development is the right way to go (but that is another discussion).

I see XP fitting within the Biz logic group (this is where I see the XP focus on the Wiki pages), but how does it deal with the need for system support code? What about frameworks? Not the kind that slips into YouArentGonnaNeedIt, but the support frameworks that you need so the Biz code has a nice, clean playground to tumble around in? Stuff like EnterpriseJavaBeans, GemstoneJ, and WebLogic Tengha are helping, but they haven't created a seamless environment yet. How does XP address this need? Does XP assume that all of the system support libraries and frameworks are in place?

-- ToddCoram

Briefly, we made a strategic decision to use GemStone, and another to retain an IO framework from the archives. One of these decisions was correct. Other systems things we built along the way, such as a new interface to our tax package. This entailed primitives in the virtual machine, stuff like that. We did some of these with outside "experts" with mixed results. Our practice now is to bring in the expert, work with her to hack the changes in, then reimplement them in our style, thus truly learning how to do it and making sure it's done our way. Non-briefly, feel free to email for offline discussion. --RonJeffries

HowToDevelopFrameworks

The trick is how far to generalize. Is Smalltalk critical? Is payroll critical? Are Chet and Rich critical? Was starting from a dead project critical?

I believe that the principles of XP are very widely applicable, and that the specific practices are widely applicable.

For example, even on a one-million-man project, I believe:

running suites of UnitTests very frequently will let development go faster than otherwise.
Having FunctionalTests will help you know whether you're done better than if you don't have them.
Writing simple code will help you get done sooner and more flexibly. (DoTheSimplestThingThatCouldPossiblyWork)
Working on what you do need instead of what you might need will keep the system cleaner and get you done sooner (YouArentGonnaNeedIt).
Having all your UserStories (use cases) broken down into small enough bites to estimate, and adding up the estimates, will give you a better CommitmentSchedule than whatever most projects are doing now.
Breaking down all UserStories into EngineeringTask s and having developers estimate those tasks (and tracking them) will give you a better IterationPlan than whatever most projects are doing now.
PairProgramming will give you faster development, higher quality, and better cross-training.
More to come ...

On a large project, you might not be able to do these things all as a group. But everyone on the team can readily do them, and they'll work better than the Level 1 process most people have now.

Please list below XP principles and practices that might NOT be useful on other (specified) kinds of projects. Offer some reasoning, please. --RonJeffries

Not in the list above, but mentioned elsewhere on XP pages are de-emphasising documentation and discouraging code ownership. These might not be useful on a project aiming at re-use over long time-periods in a distributed environment. See JeffMcKennaForces.

Separating business logic, UI, and infrastructure people defeats XP, no question. XP is good at creating applications out of situations where the optimum system must track a dialog between what is possible and what is desired, where the development of the system changes both what is possible (as developers learn) and what is desired (as the system and the world change the business environment and the users). The best way I have found to reconcile the possible and the desired is to distribute responsibility for such reconciliation across the entire team and the entire life of the project.

There is a small role to play for technology specialists, if they share the values of the rest of the team. That is, you can't have all the application people trying to do really simple things, and have the nerd-meister downloading new betas of the reusable libraries every couple hours and using every last bit of it. This marks me as a technology conservative- so be it.

I would never separate the UI and business teams. I would give up too much learning as the two worlds rubbed up against each other. You have to learn as fast as possible. It is at the edges that learning happens most (idea stolen from PermaCulture). Make the most edges you can. If I'm working on UI in the morning and business logic in the afternoon, and everybody else is too, then I can't imagine more edges than that.

--KentBeck

Kent, I worked on a project where developers would work on the UI in the morning and business logic in the afternoon and it was a nightmare. It was difficult for those less experienced with OO techniques to separate the two. This especially caused a problem because we wanted to reuse the business logic in different applications.

However, we were not doing ExtremeProgramming. I think a combination of PairProgramming and EgolessProgramming would have solved the situation. EgolessProgramming would have meant that the developer working on the UI and business logic would readily admit when he/she made a decision that compromised the desired ArchitecturalQualities? of the system. PairProgramming would have meant the situation might have been corrected as (even before) it happened.

-- HankRoark

Some things that have not gotten us to XP.

We decided to do a generic framework in an unfamiliar domain area as our first OO project, and did not hire anyone with expertise in the area.

We tried PairProgramming, but implemented it very badly.

Project leadership decreed that all of the senior developers would concentrate on the next set of risk areas, while the junior staff paired to build the well-understood functionality from cookbooks,
The pairing was assigned and permanent for three weeks,
Tasks were assigned to the pair, who did have the option of working separately, but had joint responsibility,
Since the junior staff members are located in small cubicles, both partners could not reach the terminal at the same time. Instead, one person would type, while the other sat back a few feet away and watched.

At the end of six weeks, the staff revolted. Comments such as, "I will never work with <insert partner's name here> on a project again" were heard in a developer's meeting.

We do not have ready access to the organization which needs the code. Instead, the project leader defined all of the requirements himself, had the analysts write them as use cases which were reviewed internally and then reviewed with the customer, who was only available for about one day every two weeks. Since the project leader had his own agenda, many of the requirements and priorities were not congruent with customer needs.

On the plus side, those few of us who have learned refactoring have found doing it in Java to be quite easy, and have found PairProgramming and UnitTests to be a major benefit. Whether we will be able to reinstitute some of these practices in a new project remains to be seen.

--RussellGold

I ask some questions about this scenario in PairProgrammingTheWrongWay. --AlistairCockburn

Having read much of the XP stuff, I have seen frequent reference to the notion that "ya gotta wanna". If your developers don't want to do it, you won't. What about the inverse though? How much buy-in do you need from above? How much of a grass roots effort can XP be? I would be really curious how other developer types have gone about getting their organization (esp. at the muckety-muck levels) to tolerate/accept/promote XP?

What if your group is not necessarily project-centric? IOW, our software team exists because we always have work and an undying, unending stream of projects. We were not formed to work on one single project. In fact, at current, there are 3 material products that we are developing software for. Can XP scale to this kind of situation? One of the ideas we have been toying with, and even tried once or twice is flip-flopping. Traditionally, we have cut the work up into different products and parcelled them out to different individuals. Lately, with PairProgramming, we've taken a couple of cracks at the team all working on one product for a little while, and then on the day boundary, flipping to another. This seems like the only good boundary to flip-flop on, because it provides a natural time to take a break, let the mind clear, and version existing stuff. --TravisGriggs?

In my experience, things don't come to a round conclusion on day boundaries. Aside from that, which means we might version at 10 AM, I'd try individuals flipping when they complete their story. If I wanted to flip the whole team, I might try doing it at the end of an iteration, and I'd probably go to a one-week iteration. Please keep us informed on what you try and how it seems to work out! --RonJeffries

Moved from ExtremeProgrammingLimits

What are ExtremeProgrammingLimits? - things for which ExtremeProgramming is not a solution, is not an efficient/adequate approach or better things are known to exist ?

XP is only recommended as a solution where the problem is to create working software on a finite schedule and budget. It is not claimed to work for building bridges, writing operas, or taming rhinos.

XP may not be adequate as it stands for life- or money-critical projects: you probably need more than the testing we recommend.

It does not address how you get the requirements other than by recommending to have someone who knows.

It addresses "software that works", not necessarily "software that sells".

It does not address how to refactor in the presence of large amounts of legacy software relying on existing formats of data. (I'm not sure about that one. My current project involves a largish codebase of sickly C++ which has grown into unseemly intimacy with a hundred or so tables in a SQL database; does that count ? Most of XP definitely seems to apply there.)

It does not address how to deal with projects outside of one room.

...

Three possibilities :

there are no limits.
there might be limits but the great extremos can't tell anything about them (not even if they exist). Instead they recommend for everybody to try and if the project fails, either the project hit one or the project wasn't really doing XP. So nobody has any clue as yet.
there are known limits to XP, and it's only natural to ask the people who should know what those limits are.

Now which one is it ?

Delete the above if the list atop it is a good start toward answering the question. (The longer, less focused version was moved to IfXpIsntWorkingYoureNotDoingXp as suggested.)

Answering this subsidary question might help filling out this page : "What are your guesses as to where an XP project can get in trouble, and what are your reasons for suspecting that ? -- RonJeffries"

Would it be to extreme for you to set an example ?

CategoryExtremeProgramming

See CriticalSpiritInSoftwareDevelopment, ExtremeProgrammingBoundaryConditions

EditText of this page (last edited May 1, 2003)
FindPage by browsing or searching

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006