‘Questioning XP’ Category Archives


What Is Next After Extreme Programming?

by Tony in Questioning XP

The success of XP has reawakened interest in software development methodologies. The fact that it has become popular without large organizational backing or promoting represents a large shift in the software development community.

Although you could easily be misled into thinking that XP is the ultimate approach to software development, there are many competing approaches out there. Sooner or later another approach will catch the attention of the software development community and XP will become just another way to develop software. Personally, I think that this can not happen soon enough, because the hype surrounding XP hinders reasonable discussions about where it works and how to apply it.

Overall, though, any successor or alternative to XP will have to be superlative to supplant it in teams that have a lot of experience in using XP. This is not to say that XP is the end of the line for process evolution, just than XP is very captivating for a lot of people. It is a development process that people actually enjoy using.

— Pete McBreen, Questioning Extreme Programming, Chapter 21


Developer Enjoyment of XP

by Tony in Questioning XP

There are two things that really strike me about developers who use Extreme Programming: 1) They really like programming, 2) They really like working on XP projects.

Although these observation could be dismissed as being obvious, that would be a mistake because they reveal an interesting aspect of XP – the
fact that XP considers developer enjoyment of the process important.

No wonder, then, that developers are attracted to XP, It values what developers consider to be important. It also taps into the pride in work that most developers share. At least half of the practices are intended to address code quality and maintainability. Couple this with iterative development leading to small releases so that developers can see their code going into production and it is easy to see why developers are attracted to XP.

— Pete McBreen, Questioning Extreme Programming, Chapter 20



by Tony in Questioning XP

Many projects have gotten into trouble in the past because the developers have tried to build a completely general, optimal solution. Indeed, a common joke is that some programmers would rather build an application generator (and use it to build the application) rather than simply build the application. Most of the time this is an obvious case of what Kent Beck called false feature rich, and the obvious solution is to ask the developer to do the simplest thing that could probably work.

The real problem is that the idea of build generic, optimal solutions is really seductive. After all, what could be more effective that writing a simple report generator and using it to produce the reports? It will obviously be much faster than having to develop 20 different reports.

Unfortunately, it is never that simple. All too many projects have wasted lots of time and money building a simple bit of generic infrastructure, so to address this risk Extreme Programming has an explicitly saying to warn against this mistake.

— Pete McBreen, Questioning Extreme Programming, Chapter 19


Playing to Win

by Tony in Questioning XP

I have to question the sanity of any organization that would assemble a team of novices and then claim that it is playing to win. There is a subtle mismatch between word and deed. Regardless of the software  development methodology approach selected, a team of novices is going to struggle and have a much lower probability of success than a more
experienced team. An experienced coach might be able to mitigate the worst of the risks for a small group of novices, such that they quickly learn from their mistakes, but my guess is that it would be better to have the coach take a month or two to train the novices before starting the project.

Yes, you could plausibly suggest that the collaborative practices of XP would allow a team of novices to learn faster than a traditional team of novices, but that avoids the question of why use a team of novices in the first place. Low-experience teams are hazardous to the health of any project, especially if the team members are convinced that because they know objects, design patterns, UML, and Java they are bound to be successful. Knowledge of these things helps, but there is a lot more to a successful software development team than a bunch of individuals who happen to know some esoteric technology.

— Pete McBreen, Questioning Extreme Programming, Chapter 18


Oral Documentation

by Tony in Questioning XP

Oral documentation means that XP does not really support the idea of handing an application off to the maintenance team. While personally I think this is actually a step forward, it is contrary to the way that many organizations have their maintenance departments set up. To work around this, before disbanding an XP project team, it would be useful to have the maintenance team work with the project team on the last few iterations so that they get familiar with the code.

Alternatively the Customer must schedule some user stories that request maintenance documentation that explains the overall design before they disband the team. Otherwise the maintenance team will face several months of confusion as they try to understand the application. In a way this could be seen as a hidden cost of using XP – a continuous thread of active staff to maintain the oral knowledge about the code costs real money. Disbanding an XP team without getting the team members to document the internals of the application would be unwise, but this documentation would probably fall prey to many of the ills of traditional documentation and it is very unlikely that future maintenance programmers would trust it.

— Pete McBreen, Questioning Extreme Programming, Chapter 17


Emergent Requirements

by Tony in Questioning XP

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


Benefit Without Change

by Tony in Questioning XP

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


Is The Cost of Change Really Low?

by Tony in Questioning XP

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


Ideal XP Team Size

by Tony in Questioning XP

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


Checking for Syntax Errors

by Tony in Questioning XP

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