CSC323 2010S Software Design

Extreme Programming Explained: Section 1

Kent Beck (2005). Extreme Programming Explained: Embrace Change, 2nd Edition. Section 1: Exploring XP (pp. 9-122). Boston, MA: Addison-Wesley.

XP sounds like a pretty good way of Getting Things Done In A World Where Time And People Are Finite Resources. Can it be generalized to situations like industrial activity or engineering or lab science?

I'm not sure whether the All-Caps Text suggests that you are being sarcastic. Given that Beck isn't even sure that it can be generalized to marketing, I'd say that he would not necessarily recommend generalizing it. Certainly, some key practices, such as automated testing, don't work as well in other activities.

XP is all about trust and respect and good pair programming. How will our random changing of group members affect our ability to synergize?

In the end, the class is your project team. Hence, you need to build trust with everyone in the class.

What is the note to programmers at the beginning of the book talking about?

I expect that it's a reaction to the negative aspects of professional programming that many programmers encounter. (Death march, 80-hour work week, etc.)

What is the difference between the waterfall process and the push model of development? They seem like different names for essentially the same thing to me.

There's a bit behind the scenes. Arguably, in a pure waterfall, one completes one phase before going on to the next phase. In the push model that Beck describes, the stages continue in parallel.

XP encourages only doing as much planning as necessary to get a single aspect of a project ready for deployment. If there is no overarching plan for the entire system, how can one make accurate estimates of total time needed to finish the project?

One could argue that there is no finishing an XP project, as you simply keep adding features. One might even argue that XP is the overarching plan. But, essentially, the time to build the software is similar to the sum of the costs of implementing all of the stories. Experience tells you how long each story will take and how many stories make up a reasonable piece of software.

I find the sentiment expressed in chapter 1 of Extreme Programming Explained (It's not my job to manage someone else's expectations. It's their job to manage their own expectations.) difficult to accept. I assume Beck is exaggerating, mainly trying to illustrate the importance of controlling one's anxieties about deadlines. Would it really be okay to follow that kind of thinking in a serious work environment, though?

You're taking the quote a bit out of context. The important thing he's pointing out is that you have a responsibility to accurately convey what is possible (or at least what you believe is possible) given a particular set of contraints. In the end, giving regular evidence that you work your hardest and estimate well should work in a serious work environment. However, it's also clear that for this work, other aspects of XP must be included (such as respect).

Why aren't any of these practices implemented or at least mentioned in more CS classes? I've heard or seen a few such as pair programming, and the theory of constraints but I've never heard the benefits of communication mentioned in a CS class the way they are in this book.

One might argue that presenting practices without the corresponding values and principles is pointless. But we do try to discuss many of the principles (at least in some form). We certainly talk about testing, about refactoring (which seems to have been renamed to incremental design), and even about energized programming (in the sense of time limits in the 151 exams and elsewhere). But, I'll admit, the individual faculty members don't necessarily agree with all of these practices. For example, we do think, at some level, that written documentation is good and necessary.

Many of the suggestions in this section seem like very good ideas - working on a weekly cycle, leaving room to make mistakes, etc. I don't quite understand how the ten-minute build works, though - how do they make sure it takes only ten minutes (approximately) while still building everything that needs to be built? The concept behind it makes sense and seems to fit with the rest of extreme programming's principles and values, but I'm unclear on how exactly it would work.

I haven't done enough of this in practice to know all the details, but I expect it has to do with choosing the right modularity and tests. But I'll admit that even in the larger projects I build, I rarely see more than ten minutes of build/test time.

How does pushing quality standards higher actually improve something like delivery speed? Higher quality would probably result in more easily changeable code, but I don't see how it would initially come out faster.

The claim is that catching defects earlier means that you spend less time per defect fixing them. So, in the end, the software takes less time.

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Thu Apr 8 11:41:01 2010.
The source to the document was last modified on Tue Mar 16 09:21:11 2010.
This document may be found at

You may wish to validate this document's HTML ; Valid CSS! ; Creative Commons License

Samuel A. Rebelsky,

Copyright © 2010 Samuel A. Rebelsky. This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.