Extreme Programming May Scale Up

Requirements are communicated in Stories defining what the system must do. Each Story is independent (though there are families) and specifies work that will take only about a week to do. Stories are owned by the customer, and are "modules" of the specification. They are doled out to development teams during IterationPlanning, in WorstThingsFirst order. The customer (or customer team) decides stories, eliminates duplicates, and answers questions.

Architecture (System Metaphor) is defined at the beginning of the project and is communicated primarily in the code. There is no architecture document: there is only the program.

Design is communicated among only the few people who are actually building the object, using CRC cards. Then they build it. There is no design drawing or document: there is only the program.

Intention is communicated directly in the code, not by commentary in the code.

NOTE: Discovery is made possible using powerful browsing capabilities such as are available in Smalltalk. Without the ability to quickly find (and change) references to classes and methods, might XP run into problems?

The emerging effect of these assumptions (and the other practices) is that the team feels that they are only writing the program. It's as if the program is the only artifact, and it communicates everything anyone has to know. (This is largely true, but there is an effect due to all being in the same room as well - bear with me.)

Because there are no large documents, the large documents do not have to be maintained, nor do they have to be understood. Once inculcated with the culture, developers can look anywhere in the program and see what is being done, why it is being done, and how it works.

During development of some particular functionality (over a period of a few days or a couple of weeks), a pair of developers makes all the necessary changes to all the objects that are involved in their task. Frequent release, with help from the code management tools, keeps conflicts from getting in the way.

Most of the time, each pair works almost autonomously and with almost no need for significant coordination with other teams.

Therefore, there is no obvious limit to the number of teams who can work "in parallel" on the project, once the base metaphor and core objects are in place.

It is entirely possible that a large project using XP methodology would never need to go beyond it. If more coordinating activities or documents were needed, they could be added incrementally, as needed. Worst case, it would turn into an ordinary large project. More likely it would stay light on its feet and get done much faster than the conventional way.

Someone who knows XP should try it - it might take little more than the nerve to do it. --RonJeffries

See ExtremeProgrammingCodeReviews, HundredPersonProject

It still seems that there is something missing. The overhead of communication is still there. For a very large project, there would be the possibility that stories would duplicate unless channeled through a single gatekeeper. Yes, they are, see above.

Moreover, unless DivideAndConquer is used, the code base could become so large and change so rapidly that it surpasses the limits of human attention and energy (which are rather finite).

No one of the ChryslerComprehensiveCompensation team understands all of C3. Because it is all written in the same style, any one of the C3 team CAN understand anything s/he needs to work on. Why would any one human need to look at the whole code base in a largerXP project, when (clearly?) no one understands all the code base in any other large project? What am I missing?

Just the idea that as the number of developers goes up and the number of stories to be addressed goes up also, an inevitable slow down will occur. This is because stories may require modification of the same code. Even with change control, one team may plan to do something and find that it is changing outside their control faster than they can address it with their changes. That is the best case for ExtremelyLargeExtremeProgramming?. The other possibility is that code that can be reused is not reused because the code base has increased so much that people start to duplicate without being aware of it.

I agree that ExtremeProgrammingMayScaleUp better than any other method, but I do think that human communicational overhead, whether through formal mechanisms or a shared code base, does cap what we can expect from large systems development.

I would expect TechnicalMemo(s) to become more important as ProjectLore grows beyond what can be conveyed by face to face meetings.

I would expect explicit groupware tools to be used as well. I don't know exactly what. Email for one-to-one, Wiki for many-to-many. A version control system, of course.

I sorta feel that the "duplicate without being aware of it" problem would be reduced with a good, shared, searchable, code repositary, but this has been a dream for years (eg Meyer mentions it in the early Eiffel books) and I don't think it's been properly realised yet. Maybe you'd have to build the tools you needed.

-- DaveHarris

Duplicate methods in a class can be, and should be, detected by browsing. Duplicate classes or families might be addressed by emailing around class comments every N days. People could browse them, search them for keywords, etc. --RonJeffries

I actually spoke directly with RonJeffries and some of his Chrysler colleagues tonight about the following issue, but I would like to hear from others on this topic. I like to work off-site, on the road, which would very rarely permit PairProgramming (which, to be honest, I've never tried on-site, yet). I have already incorporated much of the tenets of XP into my programming, such as UnitTests, AskTheCode, and RefactorMercilessly, and it's been very effective (and natural!). But if you have a project involving a lot a programmers working separately off-site, like a lot of the open source projects out there, can you do effective ExtremeProgramming? I would think you would need to have a good bit of diagrams and succinct documentation giving system and sub-system overviews. But without the ability to do PairProgramming, could you still call it XP if you did frequent code reviews with remote partners, mostly by e-mail? Can someone suggest other ways of, for instance, doing a large-scale open source project using XP? -- AriMeyer

Frank Maurer and Sebastien Martel did a short study at the University of Calgary where they developed a process they called MILOS to do Distributed XP. It used a Websphere server and Netmeeting to build Story Cards and to accomplish pair programming. The study can be found at http://sern.ucalgary.ca/~milos/papers/2002/MaurerMartel2002a.pdf. -- Richard Scutt

Collective code ownership won't always scale, IMHO. This is not because each team member cannot understand the code, clearly a uniform style etc helps. The problem is that the very large project usually spans many sub-domains, and it isn't practical to understand all these. Supposing C3 expanded to be one giant system to do everything at Chrysler. Would it be reasonable to expect every developer to have a working knowledge of payroll+personnel+stock inventory+double-entry accounting+marketing concepts+franchise management+buying advertising space+.....? A smaller scope version of this happens on a lot of big projects, I think. -- DaveCleal

Just a thought ... Dave's right that not every developer on the "do everything" project could know everything. However, that doesn't necessarily mean you drop CollectiveCodeOwnership. Suppose the team evolves into subteams of specialists: payroll/personnel guys, manufacturing guys, marketing guys, I don't know. The teams send delegates to IterationPlanning meetings, where stories are presented by GoalDonors as usual, broken down into engineering tasks as usual. The delegates are sufficient to do the breakdown: the specialists do most of it, and delegates from other teams deal with the interfaces. The tasks are signed up for by the specialist delegates, for the specialist group. These are then put on the specialist's whiteboard and signed up for real and estimated by the individuals who will do them. Estimates feed back to the big plan the next day.

Then coding just proceeds, with CollectiveCodeOwnership. The original partitioning tends to keep changes local to the area of expertise. but as developers do this and that, they still find themselves wanting to push methods onto Date or Person or Engine, not in their official domain. So they just do it, run the tests, and release.

As always, when an XP pair encounters some code that they don't understand, they sit down with some other folks and do a CRC session, or just call over an expert for a quick pairing on a subproject. This would be done across specialty from time to time, more commonly within, cause that's how the shape of the system would be.

I dunno, just a thought ...

It seems there are two objections to CollectiveCodeOwnership- someone might break something, and there would be too many collisions. The obvious kind of fixes won't break things- I keep sending these two messages over there, I'll make a method over there that sends the two messages. The one about collisions would have to be measured. As the code base grows, the probability of collisions grows smaller and smaller for any fixed number of people making changes. Would it be a problem? Someone will have to try it and see.

Whoever wrote that last paragraph reminds me of something important. Rather than spend our time pondering, we AskTheCode. Choosing development processes needs a similar pattern. When do we install a version control system? AskTheProcess?. When do we add an extra level of managment? AskTheProcess?. When do we require proofs of correctness as well as unit tests? AskTheProcess?. (now if I can just figure out what I'm talking about -- it must have something to do with taking the right measurements) -- GeorgeSxCowan

By narowing the scope and puting more focus on the programmer, perhaps a more scalable form of ExtremeDevelopment may be possible? --BillLaForge

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006