Columns

Hype or hyper-active? A review of 'Questioning Extreme Programming'

• By Dan Romanchik
• May 1, 2003

In Part I of “Questioning Extreme Programming,” Pete McBreen cuts right to the chase, noting that Extreme Programming (XP) is controversial because programmers are pushing their managers to allow them to use it. The reason for this, McBreen says, is that most software development processes simply don’t work, which makes developing code a frustrating operation. XP appeals to software developers because it focuses on the code, not on the process, and promises to make software development more of a creative process than a bureaucratic one.

McBreen is, however, somewhat skeptical. He asks whether XP really can make developers hyper-productive or whether it’s just hype. But it takes him a while to get around to it. In Part II of the book, McBreen delves into the philosophical underpinnings of software development methodologies. He says the main reason behind the urge to adopt a software development methodology is fear -- fear of bugs, fear of slipping schedules and so on. He then goes on to examine some of today’s popular development methodologies in this light.

McBreen is, however, somewhat skeptical. He asks whether XP really can make developers hyper-productive or whether it’s just hype. But it takes him a while to get around to it.

In Part II of the book, McBreen delves into the philosophical underpinnings of software development methodologies. He says the main reason behind the urge to adopt a software development methodology is fear -- fear of bugs, fear of slipping schedules and so on. He then goes on to examine some of today’s popular development methodologies in this light.

Finally, we get to questions about Extreme Programming. Part III of “Questioning Extreme Programming” questions XP’s core concepts in relation to not only other development methodologies, but to engineering in general. This is an interesting discussion that raises many questions about Extreme Programming as well as software development.

Part IV examines XP concepts in more detail. Among some of the chapter titles in this section are “The Source Code is the Design?,” “Test First Design?,” “Large-Scale XP?” and “Is the Cost of Change Really Low?”. The well-written answers to these questions will help readers to decide if XP makes sense for their project or company.

If Socrates had been a software developer instead of a philosopher, I suspect he would have said, “The unexamined software development methodology is not worth using.” Instead of blindly jumping onto bandwagons, it is incumbent upon us to carefully evaluate software development methodologies before we adopt them. With this book, McBreen gives us the tools to do that for Extreme Programming.

“Questioning Extreme Programming,” by Pete McBreen; Addison-Wesley, Boston, Mass., 2003.