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.
;
