Tailoring a Process to Local Conditions: Why XP Stands on Its Head


As we ve shown, XP s practices are too tightly coupled . But the ones that are most tightly coupled are also the ones that most need to be adaptable.

The hallmark of a useful software development methodology is that it s eminently adaptable. XP authors often point out that if XP isn t working for you, then you should change XP to fit. This would be good advice if it were really as simple as that, but as we showed in the first part of this chapter, tailoring XP is a potential minefield of poisonous snakes and mixed metaphors.

The situation is made even more difficult by the nature of software projects in general. We ll demonstrate now that, although XP is supposedly adaptable to a wide variety of projects, its authors have got it exactly the wrong way around. When it comes to adaptability, XP stands on its head. And in a pit of snakes, at that!

start sidebar
The Eternal Cat

Here s a little thought experiment: What happens when a strictly logical person and a flagrantly emotional person must sit down together in a meeting room and between them produce a software design?

This is similar to the joke about what happens when you tie a slice of bread, buttered side up, onto the back of a cat and then drop them from a height of about 6 feet. Just as the cat/buttered bread pair will never hit the ground, but will instead spin indefinitely just above the ground, so the logical person and emotional person will likely never reach an agreement over something as complex and prone to individual practices, habits, and opinions as a software design.

As an aside, now try repeating the experiment with not just one pair, but a team of programmers, who must all pair up and between them evolve a design over a period of, say, 12 months. Picture a roomful of spinning cats. This is why in The Mythical Man-Month, Frederick Brooks recommends the use of a project leader, a chief programmer (or surgeon ) who champions the design and holds the project true to it. Chief programmers are often regarded as control freaks, but a good chief programmer will listen to his team and incorporate their feedback into the design without compromising the overall design vision.

end sidebar
 

Logical vs. Emotional

The problem is this. There are two opposing sides to software development ”the logical and the emotional (see Figure 3-1) ”simply because we re dealing with both logical things (computers) and passionate , mostly deeply illogical things (people). These two extremes are present in every single software project, but they rarely sit comfortably together. This is a real dichotomy that has already created an underlying rift in the software community, just barely hidden from view but definitely there, creating tension, sparking off, and heating up arguments between developers over the simplest of discussions. When personalities clash , emotions flare up all too easily.


Figure 3-1. The tug of logic versus emotion in every software project

Software projects tend to draw an uneven and uncomfortable line somewhere between the two extremes, the eventual line usually being dictated by the project leaders and the culture of the organization. If anyone in the project doesn t fit into this narrow band , then tough. So in a project that sits too far one way or the other, we risk losing perfectly good staff because they just don t fit in. This is a real problem. The answer should be found in the software development methodologies that we turn to. However, many such methodologies sit rigidly either too far one way or the other ”toward the logical and dispassionate, or toward the fuzzy, gooey, warm feeling of a people-oriented process.

In Agile Software Development, [20] Alistair Cockburn identifies that no software process will work for all projects in all situations, in all organizations, and all countries . There are just too many local differences, both in culture and in circumstances. Therefore, a good software methodology is one that doesn t dictate (or prescribe ) procedures. Agile methods (and XP in particular) are sold on the basis that they are nonprescriptive (i.e., they make no assumptions or stipulations about the precise method that the developers will use to build the software).

What does tend to be overlooked, however, is that there s a core , or logical, process that should be prescribed. This is essentially how to get from A to B on a good day (where typically A is the requirements and B is working software).

start sidebar
Example of a Logical Process

An example of a logical design process (with much deliberately left out for brevity) is as follows :

  1. Iterate between the domain model (analysis-level class model) and the use cases.

  2. Use robustness analysis to review the domain model and provide early feedback on its correctness.

  3. For each use case, produce a sequence diagram.

  4. Use all the above to identify your design-level classes.

  5. Then use the sequence diagrams to allocate behaviors to these classes.

  6. Then use the class model to write the unit tests and the code.

The organizational aspect (the part that should be tailored) would involve how and where to split the development work into separate iterations (e.g., do we produce the entire analysis model first? The answer depends on both the type of project and the organization).

Visit any large bookstore and you ll see an extensive collection of titles on software design. They mostly offer off-the-shelf design processes and techniques that can each be applied in whole to different types of design problems.

end sidebar
 

The logical process is closer to the logical software end than the emotional people end. The logical process is more about how to design and build software than about how to get people to work together to design and build software.

A well-defined logical process should be applicable to a large number of software projects, regardless of the local conditions (e.g., organizational culture).

Although XP does define the core, logical process to an extent (Release Plan ˜ Iteration Plan ˜ Design ˜ Test ˜ Code ˜ Refactor), it s still a little too high level for the purposes described here. XP does, of course, also describe Test First, YAGNI, OAOO, and so on ”but these are guidelines rather than a logical, step-by-step design process.

The further up the scale you go (from logical/software to emotional/people), the more unpredictable and prone to local variations things get. Also, the higher up you go, the less process oriented methodologies tend to be. Instead they become more organization oriented ”that is, they re more to do with organizing people and things (such as the position of office furniture) than to do with prescribed step 1, step 2 processes.

The parts of the methodology that can be tailored should be the organizational aspects, because these are more prone to local variation. These aspects include how to arrange the team, how to plan the project and to what level of detail, iteration size , how often to integrate your code and rebuild the project, and so on. These are all aspects of a software process that will vary according to the local conditions. As such, no process should rely on these practices definitely being followed to the letter (or indeed at all).

Nailing Your Ducks in a Row

Ironically, XP, which is supposedly a nonprescriptive process, prescribes a lot of the organizational aspects, in particular the following:

  • Planning (the planning game)

  • Whole team (put everyone in one room, including the on-site customer)

  • Small releases

  • Pair programming

  • Continuous integration

  • Testing

  • Collective ownership

  • Sustainable pace

By prescriptive we mean that XP requires all of the preceding practices to be performed consistently, without fail, throughout the project. To make matters worse , the practices that are non-negotiable are also the ones that require a significant mind-shift from project managers and customers for XP to be adopted correctly. For example, requiring that the company change the nature of its software contracts from fixed scope, variable date to variable scope, fixed date, as well as requiring that the customer be colocated with the programming team, that the whole team be located in a single room, and that programmers always work in pairs are all potential minefields, depending on the politics of the organization.

The question is, does this actually matter? Are XP projects more likely to fail because they re too inflexible in these organizational areas? The XP literature does state that if parts of XP aren t working locally for your project, then you should change them to fit. However, they give little or no practical guidance as to how to go about tailoring XP. In fact, it s even more difficult than that. As we discussed earlier in this chapter, removing certain key practices from XP causes other parts of the process to fail. For example, emergent design is dependent on constant refactoring, which in turn is dependent on pair programming, continuous integration, testing, collective ownership, and so on.

Because XP s organizational practices are closer to the emotional end of a software project, they re the areas most prone to local variation. This means that XP is likely to be unsuited to the local culture or the local organization, or the type of project, because so many of its organizational practices are inflexible.

start example

In Chapter 15 we aim to produce a refactored version of XP that, by requiring less of a political mind-shift and being closer to the way most companies do business, should be more acceptable to a wider range of organizations.

end example
 

[20] Alistair Cockburn, Agile Software Development (New York, NY: Addison-Wesley, 2001).




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net