So far, I hear/see
Request permission to brainstorm a moment. Removal of this section constitutes refusal of permission. --RonJeffries
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?
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:
Please list below XP principles and practices that might NOT be useful on other (specified) kinds of projects. Offer some reasoning, please. --RonJeffries
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.
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.
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.
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.
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
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 :
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 ?
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006