Extreme Programming projects do not try to produce a detailed requirements document and then freeze it. Instead, the Onsite Customer is actively encouraged to steer the project by changing his mind about what exactly it is that the team is supposed to deliver.

By freezing requirements, a team is choosing to delay when it recognizes that the requirements have changed. The longer the period of the requirements freeze, the more likely that when the application is eventually delivered it will not match what the users really need. It may, however, still be a reasonable fit, allowing a new project to start to delivery additional functionality while the users happily work with the first version. For most purposes, however, if an application does not meet current requirements it is effectively a buggy application.

Slow-moving environments lend themselves to requirements freezes; fast-moving environments do not. The difference is that between efficiency and effective adaptation. In a nearly static environment, it makes sense to optimize for efficiency, so requirements can be carefully documented and baselined. In a fast-moving, dynamic environment, optimized for efficiency is completely the wrong strategy; effective
adaptation is a much better option. Rather than try to control the changes, we must instead strive to respond rapidly to each change as it occurs.

– Pete McBreen, Questioning Extreme Programming, Chapter 16

In recent years, the pressure to be more productive has led many organizations to look at alternative approaches to software development. A common problem, however, has been that even though the project team is supposed to use the new approach to be more productive, they were not supposed to stop doing any of their current software development activities. Needless to say, this is not very effective. It also creates a lot of tension for developers because they are never really sure which process they are supposed to be following.

Many organizations want to get the benefits from a new approach to software development without having to change anything. This happens all the time and is why it is sometimes necessary to talk about the difference between the espoused process and the actual process. My experience has been that the larger the gap between the espoused process and the actual process, the more stressed the team.

– Pete McBreen, Questioning Extreme Programming, Chapter 15

The original evidence for an exponential cost of change came from Boehm’s book Software Engineering Economics. What most people miss when they read this reference is that there are actually two lines on the famous graph. One supports the well known assertion that various factors combine to “make the error typically 100 times more expensive to correct in the maintenance phase on large projects than in the requirements phase.” There is also a dotted line of the graph that shows data from two smaller, less formal projects. Boehm states, “Although the effect for smaller projects is less pronounced, the 4:1 escalation in costs-to-fix between the requirements phase and the integration and test phase supports the premise.”

Interestingly, even Boehm suggests that sometimes “it may be more cost-effective to proceed with development of a first-cut prototype product rather than spend more effort pinning down requirements in full details … An even stronger case for the prototype approach can be made for small, informal projects with their 4-6:1 cost-to-fix increase, and for problem domains in which rapid prototyping capabilities are available.”

I would contend that modern object-oriented development environments are way more powerful and productive than the prototyping environments that were available back in 1981. Couple this with the Test First Development practices and it would be easy to imagine that a team could do better than a 4:1 cost-to-fix increase.

– Pete McBreen, Questioning Extreme Programming, Chapter 14

Because it is not really feasible to use larger teams in XP, teams have to find a way to delivery more value in the available time. The best way to do this is to follow the advice given by Jim Highsmith: “Start Earlier.” By avoiding wasting month and months during the early inception phases of a project, XP projects effectively start earlier and hence have more time to delivery essential functionality.

I would suggest that XP is best suited to projects with a range of 4 to 12 programmers. The good news is that a great many projects fall in into this range. Organizations are very wary of big projects, so most projects are on the small side. With software development shifting to object-oriented languages, the functionality available in the class libraries has made it easier for small teams to delivery bigger systems. Small teams of developers who really know the class libraries well can be extraordinarily productive by leveraging the power of the existing libraries.

– Pete McBreen, Questioning Extreme Programming, Chapter 13

Traditional software engineering was founded in an era when computers were fantastically expensive and the turnaround on the batch compilation of programs was very slow. Veterans of that era often joke that you could get fired for needing too many compilation runs to get a program working. Even into the middle 1980s, large programs could take several hours to compile. Small wonder programmers got really good at desk checking programs for errors before submitting the code to the compiler.

During the last few years things have changed. Computing power is so cheap that most programs can be recompiled in a few seconds, and it is rare for even large applications to take more than ten minutes to build. Hence, time spent desk checking for syntax errors is now wasted time, because the compiler will find all problems in a few seconds and position the cursor for the programmer to fix the offending line. It is now more effective to let the computer do the work.

– Pete McBreen, Questioning Extreme Programming, Chapter 12

Small teams need generalists who can take a project from start to finish in a very small time. Passing information from one person to another makes no real sense, because the time it takes to communicate all the necessary details just slows down the process. In the old days, the coding work would have been handed off, because programming used to be very slow. With a modern object-oriented programming language, and a good development environment, the coding can be fast enough that a handoff is no longer necessary. In the time it would take to write a detailed program specification, the designer can have the program written and tested.

XP teams tackle larger projects, so it makes sense to specialize and have some handoffs. The choice that XP makes is to keep as many as possible of the design-related activities concentrated in one role – the programmer. It then makes the customer responsible for capturing the requirements and handing them off to the programmers and the testers, who are responsible for automating the acceptance tests. In this way, XP tries to function as much as possible like a very small team.

– Pete McBreen, Questioning Extreme Programming, Chapter 11

One very interesting aspect of XP is its lack of specialisation among the developers. Indeed, XP actively encourages a level of cross-training that is unheard of in most other approaches. This can be very useful because it lessens the risk that progress will be slowed as a result of having to wait for one key individual to perform a task.

XP is a good counterexample to the idea that role specialisation is useful in software development. Although there are strong arguments in favour of specialisation for mechanical tasks, the arguments for efficiency through specialisation are inconclusive for intellectual tasks. By making the programmers responsible for doing their own design, XP avoids the inefficiencies and miscommunications that can arise when design ideas are passed from a designer to an implementer.

– Pete McBreen, Questioning Extreme Programming, Chapter 10

Pair programming is a very controversial part of XP, and some programmers are going to be unwilling to even try the practice. True, most who try it for long enough report liking it, but there are some who are vehemently opposed to pair programming. Although there is some evidence that pair programming is more effective that working alone, more studies need to be done with experienced practitioners.

Interestingly, many of the objections to Pair Programming come from the mistaken idea that software development is a mechanical task. Hence, the assumption is that two people working on one task are inefficient and slow. It is an open question as to when this type of mechanical metaphor will cease to dominate thinking about software development.

– Pete McBreen, Questioning Extreme Programming, Chapter 9

Of all the practices of XP, Test First Development is the most counterintuitive of them all. It is probably also the most powerful of them all for promoting the necessary paradigm shift for understanding and benefiting from XP. The idea behind Test First Development is very simple: before you change the behaviour of the production code you must have a failing test.

A failing test is immensely useful because it tells you when you are done. By shifting the traditional sequence of development around so that the test are the first things that are created, developers get feedback about whether their code is correct within seconds of writing the code.

This has a very dramatic effect on the feel of programming and goes a long way toward addressing concerns about the defect rate.

Test First Development feels exceedingly strange for programmers when they first encounter it. In the old days, programmers used to pride themselves on the fact that they could write an entire program and have it compile error free the first time. Now they are expected to get lots of errors deliberately every day. Although this feels really natural for XP developers, getting developers even to attempt this style can be difficult.

– Pete McBreen, Questioning Extreme Programming, Chapter 8