
1-star reviews of 'Extreme Programming' - narfz
http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/product-reviews/0201616416/ref=cm_cr_pr_top_recent?ie=UTF8&filterBy=addOneStar&showViewpoints=0&sortBy=bySubmissionDateDescending
======
ekidd
In the late 90s, I worked in two different Lisp companies (one of which went
on to become quite successful). They were, in many ways, far more modern than
the average C++ shop of the era: They accepted that programming could be
exploratory, that unit tests were a great thing, and that you wouldn't know
what you wanted until after you'd already built half of it.

And yet…

I remember programmers who disappeared for months at a time to work on "their"
modules. Integration phases where we tried to combine wildly incompatible
components after 6 months of separate work. The breathless joy of seeing an
actual regression test suite for the first time. The endless arguments trying
to find the ideal design. And we all thought this was the "right way" to
develop software!

I remember Beck's _Extreme Programming_. For me, it came as a bolt from the
sky, obviously radical and brilliant. It turned me from a clueless junior
programmer into somebody who took over and turned around a 150,000 line,
14-year-old C++ project, a project which everybody thought had succumbed to
terminal bit rot.

Unit tests. Short iterations. The planning game, a.k.a., "Here, let me take
your list of features, and tell you what each one costs. Now you decide what
order we build them in." Man, does it bring back memories.

Of course, that was pretty much the shining high point. Within just a few
years, Beck's idiosyncratic personal vision had been replaced by the "agile
manifesto", and then by an entire consulting industry. Good riddance to all
that.

But you know, it's been a long time since I heard somebody say "integration
phase" or "object-oriented analysis." And I couldn't be happier.

~~~
nickbauman
I had a similar epiphany when I read Beck's book around 2000 or so. I don't
think the Agile community has added much if anything to the work Beck
originally laid out, either. In fact the term "Scrummerfall" is now in common
usage here in Minneapolis.

~~~
Nimi
Well, that was somewhat predictable. You've got a lot of managers. Some of
them don't like to code, and regardless, all of them certainly need to be
employed. What would they do if their shop started doing XP? One or two can
become PMs or coaches, but what happens if you have much more managers?

At the risk of sounding somewhat loony, I think Marx said something about the
middle class (in his definition: the class between the proletariat engaging in
production, and the ruling class of capitalists) trying to preserve the
benefits it gets from its social role. Can't find a citation though.

~~~
vanderZwan
It's funny that there is a quote, recently made famous by Civ 4, stating "the
bureaucracy is expanding to meet the expanding needs of the bureaucracy,"
while management would be a much better fit than bureaucracy IMO.

Also, in practice civil services are _much_ more efficient in many situations
than their market alternatives (possibly because they pretty much epitomise
the proletariat you mentioned).

~~~
mathattack
I haven't shared your experience with efficient civil service. In the US,
everything without market pressure fills with bloat.

~~~
vanderZwan
In terms of _customer interaction_ it's obviously a terrible experience, even
when you do meet helpful people. But have you actually gone through a process
where the civil service was more expensive than the market alternative?

By and large, the empirical data does not support the public perception of
government (and remember there are many layers of "government") being hugely
wasteful, especially when looking at money wasted on administration compared
to the market.

[http://www.governmentisgood.com/articles.php?aid=20](http://www.governmentisgood.com/articles.php?aid=20)

Also, the government is under a market pressure of a sort: can I "sell" this
budget to the people who have to vote for me as a politician?

EDIT: Of course, I'm not saying that civil service is good by definition -
just that when done right there are places where it's a much better solution
than a free market one. Also, corruption can be an issue of course - as I
understand one of the big reasons Greece is in trouble is because of the
corrupt civil service, which caused it to bloat as well.

~~~
mathattack
Catholic schools generally get by on less money per puli than public. State
run liquor stores are more expensive than private.

Even still, it's hard to be more expensive when your cost of capital is near
zero. (Taxpayers foot the bill)

~~~
vanderZwan
> State run liquor stores are more expensive than private.

You mean the liquor stores in countries where liquor is extra heavily taxed in
an attempt to curb alcoholism? Yeah, no. In fact, that that is exactly what I
mean: you are confusing cost-to-the-consumer with cost-to-run.

------
abolibibelot
Some of the criticisms are still valid: there's a definite "gossip magazine
diet plan" vibe to the book, even if the clean cut from waterfall or iterative
process horrors (Rational Unified Process anyone?) was sorely needed.

The criticisms about no metrics supporting the book assertions are valid too
(we have more metrics now, though).

That said, a lot of things in this book are now considered good engineering
practices, and the methodology guys have come back with a vengeance with the
Agile/Scrum/Lean/Whatever waves that filled the blanks left by XP (and ensured
a nice revenue stream for pure process consultants).

~~~
praptak
> the clean cut from waterfall

...was in fact a strawman. The whole horrible waterfall process was an urban
legend: [http://postagilist.wordpress.com/2012/06/13/the-perennial-
wa...](http://postagilist.wordpress.com/2012/06/13/the-perennial-waterfall-
strawmanmyth/)

~~~
SideburnsOfDoom
> The whole horrible waterfall process was an urban legend

Bullshit.

Source: I lived through it in the early and mid 1990s.

~~~
logfromblammo
I'm living through it RIGHT NOW. I'll give you one guess who pushed it on us.
And I'll even give you a hint: it almost rhymes with "rubbermint".

~~~
SideburnsOfDoom
Waterfall is only mostly dead. I'm told that the reason why the public sector
prefers price-and-scope-up-front is that the alternative of "we'll keep
delivering things as long as you keep paying us" sounds to them far too much
like ways that they have been ripped off badly in the past when buying tanks,
bridges, etc.

However there is hope. www.gov.uk is a notable recent success story.
[https://www.gov.uk/service-manual/agile](https://www.gov.uk/service-
manual/agile)

The difference is that in the early 1990s, most of us thought that larger
software projects were just _like that_. We didn't know any better.

~~~
vonmoltke
That is absolutely the reason. On top of that, the only reason they want to
use iterations (along with the dreaded inchstone) is so they can use Microsoft
Project as a progress bar. If you try to change your iteration deliverables
(that were set three years ago) because of actual project issues, you get a
ration of shit from the government and their advisors.

------
galaktor
my favorite one so far. from my POV today, if I didn't know this was a one-
star review I might mistake it for a positive review :-) (except maybe for the
obvious "worst practices" comment at the end)

\-----------------

This book advocates extreme coding. It's a disguised way to legitimize "dive-
into-coding" with no proper analysis and design. This author advocates little
if any comments, documentation etc. He actually states that "design is in the
code" and documents get out of date and that's an excuse not to do it. How is
that in comparison to the "traceability" principle advocated so strongly by
Jacobson and Rumbaugh who believe that the final code should be traced back to
the analysis documents (use cases in Jacobson book) He advocates programming
in pair instead of code reviews! In short, this book gathers the industry
"worst practices" exactly the opposite of OMT, OOSE, RUP etc.

~~~
jheriko
> This author advocates little if any comments, documentation etc.

I'm very much of the opinion that good code self documents, and excessive use
of comments and documentation is a crutch for bad code.

Some optimised code might be really incomprehensible without commnets, but its
the exception rather than the case. By far my biggest use of comments is to
highlight inadequate or rushed code that should be revisited later (i.e. TODO:
or HACK: rather than NOTE:).

Don't get me wrong - design and documentation is useful in practice as well as
being the 'theoretical ideal' that I think should be striven towards. Diving
in and making a mess to fix stuff or diverging from an original design is bad
in theory - in practice it is a necessary evil with tight deadlines or when
rescuing a project that is already in a seriously bad state - or even when the
original design was naive or even impossible because it came from an
inexperienced or otherwise inadequate source.

~~~
enraged_camel
>>I'm very much of the opinion that good code self documents, and excessive
use of comments and documentation is a crutch for bad code.

I'm very much of the opinion that you are very much of the wrong opinion.

"Good code self-documents" is a myth. Most programmers have trouble coming
back and reading _their own code_ , much less other programmers' codes.
Comments and documentation written in spoken language ensure that the code can
be understood much more quickly and efficiently and any misunderstandings are
prevented.

~~~
hamburglar
The fatal problem with the notion that the code is the documentation is the
fact that the code only tells you what the code _does_ , as opposed to what
it's _designed_ to do. How do you know a behavior you observe by reading the
code isn't a bug which is going to be fixed next week? Or an arbitrary
implementation detail that isn't guaranteed? That is what docs and interfaces
and specs are for. "The code is the documentation" only works if the code is
immutable.

~~~
hnriot
Nonsense. When you read the code you need to know what it does, not what the
programmer had intended, then, and only then, will you stand any hope of
fixing bugs.

well chosen function and variable names tell you the intention, if it's
modular enough then it will all make sense when you read it.

If people could just get over this documentation phase that programming went
through in the 80's and 90's due to languages containing obtuse syntax and
being so low level you had to hold a dozen things in your head at once (I'm
thinking of you COM) - but in this era, with languages that operate at a high
level of abstraction the era of documenting the code is over.

"The code is the documentation only works if the code is immutable."

that's actually backwards. If you want to stand any chance of changing the
code then it should be readable and well structured, not well documented.

~~~
wonderzombie
I'm skeptical. How do you know what's intended behavior and what isn't if you
don't know _why_ the code is structured the way it is? Understanding what it
does is necessary but not sufficient. You risk introducing more bugs if you
don't understand _why_ the code does what it does.

"well chosen function and variable names tell you the intention, if it's
modular enough then it will all make sense when you read it."

The two hardest things in computer science are concurrency and naming things.
Oh, and off-by-one errors.

~~~
PeterisP
If the code doesn't match what's intended, it's most likely because the
original implementator misunderstood it, or didn't think of a particular edge
case - and thus the comments won't reflect that as well.

You look at code to determine what exactly the system does, but in order to
determine what exactly the system _should_ do, you need to look at the users
needs or the business process, the code+comments can't tell you that.

------
ams6110
The comment about pair programming resonated with me: _What Mr. Beck writes
about the paired-programming aspect is contrary to common sense and anyone
even the slightest inkling of perception into the personality traits of
developers._

Pair programming was THE most distasteful, unpleasant thing I have ever done
in any employment. And I include in that my very first job which included
cleaning grease traps and bathrooms at McDonalds.

~~~
bitwize
Gurdjieff said that the path to spiritual development is to like what _it_
does not like.

If developers do not like pair programming, is it a problem with pair
programming or is it a problem with developers, specifically their
unconscious, machine-like _it_?

The whole point of XP is not only to go against management best practice but
also against the comfortable habits of most software developers, in an effort
to make them better developers.

~~~
andrewflnr
Pushing against arbitrary comfortable habits is not a way to become better at
anything. Some of those habits/inhibitions have very good reasons.

------
Glide
I'm reading the reviews and I realize that I don't have the background and
years of experience to understand the software development world as it was in
the year 2000 (I graduated in 2006).

I get some of it, because of war stories. But I know I'm missing a huge piece
of it.

Like when did some of the older practices come about? Was it in the 90s? Late
90s? 80s? Are most of the reviewers curmudgeons that that watched the SDLC
landscape change before their very eyes as their certifications lost value?

~~~
nickbauman
If you mean Waterfall, the term was adapted from civil engineering, which of
course made a lot of sense for software (sarcasm). One of the earliest papers
on the process was in the 70s by William Royce where the term waterfall was
used to describe software development at its worst.

~~~
mariusz79
Like it or not but the waterfall method does make a lot of sense in software
development. It may be useless if you're trying to create another billion
dollar useless web app, but is very helpful when you have to create software
for mission-critical applications.

~~~
sandfox
"mission critical"...

~~~
alextingle
Yeah. Mission critical. It's not just a buzz word - there exists software that
is _critical_ to completion of the _mission_.

Examples: Missile guidance system. Space probe communication subroutine.

------
bazzargh
The reviews complaining about evidence did have a point. At the time, XP was
based on experiences at Chrysler implementing the C3 project - which was
canned
[http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation](http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation)

Though tbh the same could be said of any of the mountains of methodology books
we waded through in the 90s. The word 'evidence' appears precisely once in the
RUP white paper, and it's not in reference to evidence for RUP itself being
effective.

~~~
robin2
Projects can be canned for all sorts of reasons, but from what I recall the
people involved in C3 blamed the Chrysler management. Perhaps the latter were
more interested in having a working payroll system than inventing the future
of software development.

One of the criticisms I remember some people making of XP when it first came
to prominence was that it shifted a lot of the hard work of software
development onto the customer, or rather the customer representative;
certainly, ever since I heard about what happened to the first XP customer
representative (see
[http://www.coldewey.com/publikationen/conferences/oopsla2001...](http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html))
I've taken comments about XP being a humane methodology with a pinch of salt.

~~~
bazzargh
I don't disagree with what you say about C3; my comment is more to do with the
"see one-write one" nature of software books. Even though some books turn out
surprisingly well, there's a distinct lack of depth and statistical analysis
in the field.

------
rubiquity
Robert C. Martin (known as "Uncle Bob" to many) wrote a blog post somewhat
related to this recently. The gist is that Extreme Programming the name is
dead because Extreme Programming the principles have been (mostly) widely
adopted. It's a great read and I recommend checking it out.

[http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-
Kent....](http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html)

------
gaius
... And they were completely right. Who does "extreme programming" nowadays?
It was a cult, not a serious software engineering methodology.

~~~
parasubvert
No. In college, I followed the c2 wiki where XP was crafted, out of the ashes
of the Smalltalk-based Chrysler payroll system.

It was a bunch of practitioners sick of being told by MBA-types (or modelling
"architects" that couldn't code) of the proper way to write software.

Almost everyone in modern software development has been impacted by XP, if you
think through some of the practices that almost no one mainstream had heard of
or were discussing in 1999 until XP:

\- Customer is on the team (Often the biggest factor in IT projects)

\- Test driven development (now BDD)

\- Continuous integration (now Continuous delivery and Devops)

\- Design improvement (refactoring)

\- Small releases (now "Lean Startups")

\- Planning game (or estimation without Gantt charts and WBS)

Detractors focus on the controversial practices like pair programming as if
they were lunatic. Or on consultants making money flogging a crap methodology.
I don't think consultants could make money on XP back in the day - it was too
foreign and extreme.

Agile was born off the fumes of XP, to give people methodological freedom
while agreeing to the same principles. This unfortunately enabled legions of
consultants to invent their own whatever-the-hell method for their client and
subject employees to it. But it also helped some teams to deliver faster and
higher quality than they would have otherwise.

~~~
gaius
XP - to actually _be_ XP - is no less prescriptive. Either you follow the
12-step program, or you're a heretic. Now small-a agile is certainly a good
thing - but like Nietzsche I am suspicious of any attempt to systematize what
should be organic.

~~~
benjiweber
One of the XP rules is "fix XP when it breaks". I dispute that it is
prescriptive. Retrospectives provide a mechanism for changing process.

~~~
Jtsummers
For the curious [1]. Which brings up a point that I try to make with
colleagues about _any_ method/process. If you apply them blindly you might get
lucky, but you'll probably get terrible results. They have to be modified to
suit the personalities and capabilities and needs of the team, the company,
the industry.

[1]
[http://www.extremeprogramming.org/rules/fixit.html](http://www.extremeprogramming.org/rules/fixit.html)

------
jheriko
[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

~~~
robin2
I'd have thought
[http://zedshaw.com/essays/c2i2_hypothesis.html](http://zedshaw.com/essays/c2i2_hypothesis.html)
would be more relevant here.

------
dpweb
Hopefully we've evolved to the point where we can reject any dogmatic approach
and realize that there exists certain good practices that can be applied - but
it depends on the environment we find ourselves in, size and makeup of
available team, timeframe, existing rules we have to adhere to for the
particular project etc.. No silver bullet, but we rehash these debates
endlessly.

------
hyp0
Fred Brooks advocated most aspects of extreme programming in 1975 (MM-M).

------
codegeek
Whenever I see/hear the word "extreme" in the context of anything, it sounds
like a cult to me. Obligatory reference [0]

[0]
[http://www.youtube.com/watch?v=FO2Abp0FbA0](http://www.youtube.com/watch?v=FO2Abp0FbA0)

------
DavidHogue
And today most people I know who mention it keep saying XP when they mean pair
programming. Not as if it's one of many practices in XP, but as if the two
were synonymous. Please tell me this isn't common.

~~~
parasubvert
People latch on to what aspect they don't like of a thing and it becomes
synonymous with the thing itself.

With XP, sadly, this is true. Most times you bring up the XP practices
individually, and they're "good ideas". You say XP, and they say "fuck
pairing!"

------
danbruc
What's the problem with pair programming?

