When XP Starts to Fail
Another question is one of scaling. It is certainly not possible to start up a 100 person project and use XP. Don t do it. Won t work. No discussion. However, it is certainly capable of organizing the work of 10 programmers. And 10 programmers going fast, doing what is valuable to the customer and not doing what isn t valuable to the customer, can get a lot done. [16]
The various Voice of eXPerience reports suggest to us that the cracks in XP show up even on small projects. However (as the ATLAS case study shows), the cracks can turn into gaping chasms as the project scales up.
Particular areas of concern are as follows :
-
Hand-written story cards (if several programmers need to look at the same card, do they time-share?)
-
Reliance on oral documentation to fill in the details
-
Collective ownership
-
The XP coach
-
The on-site customer
-
Communal coding room
-
Emergent architecture
Let s look at each of these in turn, starting with the first two.
Hand-Written Story Cards and Oral Documentation
A prime example of scalability problems in XP is the practical reality of handwritten story cards (as opposed to the theoretical advantages). Very little text gets written on the cards themselves . Story cards rely heavily on verbal communication (or so-called oral documentation) to fill in the large amounts of missing information. It s primarily this reliance on oral documentation that means an XP project doesn t work well on large projects. Success of the project relies heavily on the team communicating well and on the whole team being in a single room.
 |
For more about the problems of oral documentation, see Chapter 7.
| |
Collective Ownership
Collective ownership in a small-scale project has its impracticalities. However, the problems are more obvious in larger projects with separate teams . If the overall architecture is emerging and evolving, does that mean that team A is allowed to go in and change the code of team B? This question remains unanswered in XP.
| |
The impracticalities of collective ownership in a small-scale project are discussed in the section What If Programmers Take Ownership of Code? in Chapter 3.
| |
In XP, the programmer pair that refactors a piece of code is responsible for running the tests for the whole system and for fixing any part of the system that gets broken by their changes. In a large project, this would mean diving into another part of the project that is being handled by a separate team and changing that team s code. This would almost certainly cause problems, because communication between the teams is much lower than if they were a single, colocated team. So if the programmers can t dive in and change any part of the code, then their ability to evolve the architecture becomes severely stifled.
XP Coach
Another area that prevents XP from scaling well is the XP coach. Because so much of XP relies on the team s adherence to the 12 practices, it takes a dedicated, observant, and unfailingly diligent coach to keep the project on track.
The impact this has on scalability is described in Questioning Extreme Programming :
The need for a coach may be a critical limitation of XP, if only because of the difficulty of locating qualified coaches. It may also put a restraint on how large an XP team can grow, because one coach can handle only so many people. After all, if there were 20 people in the team, at best the coach would have less than two hours with each person every week. [17]
(Actually, the coach would have 4 hours, assuming he can see the people in pairs, but the problem is still a significant one.)
Of course, a large team with a serious have-a-go attitude could still bite the XP bullet and launch into an XP project, hoping that among them they have sufficient eXPerience so that the coach can concentrate her time on the XP newbies on the team. However, the coach s role isn t simply about teaching XP, it s also about keeping a close eye out for people who are beginning to stray from the path ” catching deviations early enough to prevent them from impacting the project. Because the XP practices are high discipline, even experienced XPers will inevitably slip from time to time.
| |
For more about how the XP coach s performance can impact an XP project, see Chapter 6. Also see the section What If the XP Coach Falls Asleep? in Chapter 3.
| |
| |
In non-XP projects, the closest thing to the coach is probably the team leader. Just like the coach, the team leader wears many hats. His expert skill-set must include programming, architecture (to get the big picture and communicate this to the rest of the team), process engineering, and interpersonal skills.
One major difference, however, is that in XP the coach isn t specifically in charge. His role could be thought of as passive aggressive . In other words, he must keep the team on track and enforce the rules, but he must do it in such a way that he is suggesting the improvements rather than telling people what to do.
The coach is there as an advisor rather than a leader. He is the Spock (science officer) in a team of rampaging Kirks. ( Captain(s), I strongly advise you to raise shields . )
This makes his job doubly difficult. Unlike the team leader role, the coach has no teeth (figuratively speaking). This, coupled with collective ownership, is another aspect of XP that increases the power of the proletariat programmer.
| |
We discuss Marxist aspects of XP in Chapter 4.
| |
A coach who overrules the programmers in an attempt to keep the project moving risks gaining a reputation as a control freak ”domineering, inflexible , bossy ”the complete opposite of what XP is trying to achieve. In a hostile team environment, the coach is in danger of always grappling for power, never quite being in control.
Conversely, because the team leader is afforded control by her job description (and assuming she is backed up by her managers), she doesn t need to aspire to be in control. Instead, she can approach team issues and conflicts from the opposite direction: She delegates decisions and offers compromises to the programmers as she sees fit. The difference, in terms of keeping the project efficiently on track, is profound.
| |
On-site Customer
We covered the overworked on-site customer in Chapter 5, so for now we will simply ask, In a project that has too many developers to fit in one room, where does the on-site customer go?
Communal Coding Room
Many of XP s practices rely on the osmotic communication gained from cramming all of the programmers and analysts into a single room. As soon as there are too many programmers to squeeze in, then the benefits are replaced with risks (risks of lost information, misunderstandings, and so on).
Emergent Architecture
It is worth repeating this quote from Chapter 12:
| GROUCHO | The larger the scale, the more you must rely on emergence. [18] |
This is one of the more extreme of the Extremo quotes. It is also directly at odds with our own experience of design on large projects (Doug, in particular, has worked on some pretty large-scale projects [19] ).
Emergent architecture can work, but realistically only for small-scale projects. The architecture could be divided into smaller subarchitectures that are then allowed to evolve incrementally (where each subarchitecture is handled by a different team). However, there isn t likely to be any real cohesion between the different parts of the project. It s quite likely that the teams will end up with an alphabet-spaghetti architecture in which nothing quite fits together.
XP counters this to an extent with its metaphor practice, the theory being that a common architectural metaphor will keep the different areas of design consistent. However, as we discussed in the case study of the 50-person ATLAS project, XPers have found the metaphor practice to be insufficient on large projects.
What is really needed for such a project is a single documented architecture that can be shared by all the teams involved. The architecture document could be produced incrementally, but this introduces its own problems as each team tries to pull it in a different direction.
| |
We discuss emergent architecture further in Chapter 12.
| |
| |
Okay, so you say scalability isn t an issue for you because your projects are generally small. So, XP s still the best approach for small projects, right? Well, maybe not. Here, Doug describes a process that s almost the exact opposite of XP, showing that our refactored process in the next chapter is definitely just one out of myriad alternatives to XP. There are many different universes out there.
During my 15 years or so of actively writing code, I generally observed that about 5% of the programmers accounted for 95% of the meaningful work that got done. In my later years of programming, I modified this conclusion somewhat and became convinced that 5% of the programmers accounted for 110% of the meaningful work because the crew that hung around the coffee machine and the social butterflies who wandered around from office to office chatting generally didn t produce anything useful and distracted the folks who did the real work. I always tried to be in the good 5% and had pretty reasonable success at doing so. I also found that people in that good 5% quickly learned to recognize one another. So, when I started working on a new project, I always learned to look for them right away (generally they were the ones with a line of people stretching behind their desk waiting to ask them how something worked). Over the years, I became friends with a lot of these folks.
Eventually I decided to start my own business, which originally involved me writing code in my living room. Gradually, I added a few other programmers out of my group of overachieving friends, and they all started writing code from home as well. As a couple of years progressed, I stopped writing code and spent more of my time managing what the other programmers were doing. I generally carved out particular chunks of programming tasks and assigned one to a programmer. For example, one person worked on a diagram editor, another worked on a multiuser dictionary, and another worked on an import/export/model merge utility program. Everybody worked from home, and everybody negotiated their interfaces with the other folks via e-mail and through me. We built about a quarter of a million lines of code this way over a period of maybe 4 years with a team of six people. Each programmer would come into the office and meet with me once every couple of weeks for an hour or two. We did everything else by e-mail. Everybody tested their own code, and we had very few integration problems.
I ve often informally referred to this approach as SP, or Small Projects . And I think it s a perfectly good approach for small projects, although it wouldn t work for everything, nor would it work for everybody. Its strength is that it lets talented programmers work undisturbed in an environment they re comfortable in. It completely avoids the situation where the social butterflies on the project get to hitch a free ride on the backs of the talented folks and get equal credit for any success that might happen, which is guaranteed to be the case with constantly rotating pair programmers. It relies on having a chief architect who is capable of recognizing and hiring smart programmers, and capable of understanding enough of the programming details of each subsystem to ensure the overall integrity of the project. It s almost the diametric opposite of XP. And it works really well ”at least it did for us.
The point really being that it s no big trick to come up with a process that works for tiny projects. Almost any process will do for a tiny project. The trick is coming up with a process that does scale. And that ain t XP.
| |
| |
| FANGS | The scalability snake is twice as deadly as its brethren because
|
As the project codebase increases, a little refactoring can work wonders on the design. In fact, this is an essential aspect of keeping the design simple and extensible. However, emergent design (which mainly involves refactoring) is labor intensive , very high discipline, and above all requires a high level of communication between all members of the team. It requires all the other XP practices to be in place to prevent all the other snakes from breaking loose.
So it stands to reason that the larger the project, the more you need to do upfront design (the project can still be broken into smaller iterations ”just not run through a blender ). However, the Extremo thinking is the reverse: The larger the project, the more you should rely on emergence.
XP s scalability problems occur because as the team size grows, the cost of communication increases. Osmotic communication, which XP relies upon heavily as a replacement for detailed documentation, becomes more difficult with more people in the room (or in different rooms). Osmotic communication is still important and its benefits shouldn t be ignored, but relying on it to keep the project from falling apart is a risky practice. It also becomes riskier as the team size gets bigger.
| |
| |
| SOLUTION | The solution, we feel, is pretty obvious, really: Follow a development process that embraces requirements and design documentation. It s possible to do this and still keep the project agile. |
Keeping design documentation up-to-date can be a burden (depending on how off-the-mark the original design was). This can be mitigated by doing the following:
-
Maintaining only a core set of documentation (e.g., class and sequence diagrams), discarding diagrams that are no longer needed once the class model is fairly mature (e.g., robustness diagrams).
-
Following effective design techniques (including prototyping) to get the original design right.
-
Breaking the project into subsystems, individually designed. Produce an overall architecture up front so that everything will fit together and all teams involved are on a level playing field. Then break the project into subsystems spread over monthly iterations. Design in detail for the next two or three iterations. Besides the usual advantages of an iterative approach, this gives us the benefits that we would have got from XP s evolutionary design approach (only without the associated risks).
| |
[16] Kent Beck posting to OTUG ( http://www.rational.com), subject: XP and the real world, March 1, 1999.
[17] Pete McBreen, Questioning Extreme Programming (New York, NY: Addison-Wesley, 2002), p. 87.
[18] Kent Beck posting to the C2 Wiki page Can An Architecture Emerge, http://c2.com/cgi/wiki?CanAnArchitectureEmerge.
[19] One of Doug s favorite mental images is to imagine emergent architecture on something like a really big jet-fighter project. Developed over a decade or so by multiple companies, with multiple teams participating within each company, all geographically distributed, building real-time embedded software that has to respond in the millisecond/microsecond time frame or people die ”really quickly.
EAN: 2147483647
Pages: 156