Christopher Smith wrote:
1) Ward and Kent were a team going at least as far back to their days at
Tektronix in the 80's. Almost all of Kent's "fame" and "success" was in
collaboration with Ward. So, suggesting Kent was accomplished but Ward
was not is just silly.
2) You heard of CRC cards?
3) You heard of Wiki's?
4) You heard of Design Patterns?
Where's the *code*?
I suggested Beck because of JUnit. It seems to be the only project of
any size this bunch has done that has *worked*. And, JUnit, in its
original incarnation, wasn't even that large.
They have the Eric Raymond problem. Loud mouth, many publications,
little code.
They lead the engineering effort. They did not lead the project. Even if
you make all the right engineering decisions, it is entirely possible
(even likely) that your project will be a failure. Such is life.
No. And this is why software development never gets any better. "It's
nobody's fault." Spare me.
When I make right engineering decisions, a chip works. When someone
else makes right engineering decisions, a building stands. When we make
bad decisions, things fail.
A process that does not work because of "political considerations" still
*does not work*.
Hmm... do you have a process that prevents your company from being
acquired by a big multinational that "shitcans" everyone?
You finish the project. On time. When you said it would be delivered.
This bunch said they could get the payroll systems integrated in *4
years*. That's 1999. Everybody got canned in 2000. After the program
was clearly a failure. I have seen mediocre teams deliver payroll
program unifications in 4 years.
How many years are they supposed to get? Classic XP--the blame is
always somewhere else.
First of all, they delivered something that handled the payroll for
~10,000 employees just over a year after Beck arrived (and you can
imagine it took a while to get XP practices in place, particularly since
they were inventing the methodology as they went along).
Which was several thousand less than the smallest *working* payroll
program. And they couldn't manage to scale it up because they had
fundamental architectural problems which XP is supposed to prevent.
Just refactor it, right? You have all the tests and change is cheap, right?
Because, you know, taking a working program and extending it to cover
the new cases is *boring*. Refactoring the old code to make it better
is *boring*. Writing test cases for the old program so that when you
actually make modifications you know that you didn't break anything is
*boring*. Better to rewrite everything from scratch with a "Shiny, new
language and process! Yay!"
I'm not sure what you're trying to say here. XP practitioners would
argue strongly for the stuff you've labeled as "boring", and AFAIK
neither of these projects involved changing which language was being used.
Really? C3 was in Smalltalk to start? I have never heard that before.
And, if the XP bunch would advocate that, *why didn't they do it*!
At no point did they add a set of regression tests to one of the old
systems, refactor it into something useful, and then merge one of the
other systems in. In 4 years, they would have had at least 1 less
payroll system. That is, at least, a qualified success.
Actually, there is data from both the CCC project and the VCAPS
project, let alone subsequent studies. Then there's all the stuff that
came before that. As Kent Beck is fond of saying, "XP isn't so much a
new methodology as a new branding of existing best practices". Let's see
what some of these controversial principles are:
<sarcasm>
Sarcasm requires knowing what is obviously correct. You do not evince
such accuracy.
1) Unit tests. Yeah, hard to find people who think these are a good
idea. This stuff has never been shown to help. That's why nobody does it
any more.
Good programmers always did this. However, XP are adherents to "test
first". "Test first" does not have the blind adherents that it used to.
Testing too early while code is very malleable winds up wasting large
chunks of time. Quite a few people have moved to "start writing tests
when you start hunting bugs"
2) Acceptance tests for representing customer requirements and
validating that you are making those requirements. Can't find a
contractor who likes that.
Sure, except that this is the *only* documentation that a contractor
gets in XP. Last time I checked, that would make a contractor *very*
unhappy.
3) Bringing developers and customers together for release planning. This
has disaster written all over it. You get much more realistic release
plans if the customer does the planning by themselves.
No argument. However, XP does not have a monopoly of pulling customers
and developers together, nor does it have a magic bullet for why it is
easier. This problem has the same complexity whether you are doing XP
or not.
4) Peer reviews. Everyone knows that if other developers look at your
code, they just find more problems and learn nothing about how it works.
Uh, uh. It's called "pair programming". You don't get to choose the
good one (peer reviews), XP is "all or nothing", remember.
The 3 controlled studies of pair programming show that pair programming
is a net loss in effort and a net wash in defects.
5) Show the customer application prototypes ASAP and collect feedback.
That takes all the suspense out of the release. The customer doesn't get
to enjoy the surprise. Waterfalls are fun.
<sarcasm>
Sure, because we all know that a prototype completely reflects all the
required complexity of a project.
</sarcasm>
Let's pull a great quote on this from Alan Oppenheim:
"I realized many years ago when doing a major project on my home that
you can paint 90 percent of a room in 10 percent of the time. The walls
are easy. It is the careful attention to the trim and other fine
details that makes the difference."
6) Don't implement behavior that you don't need (AKA KISS). Everyone
knows you get done sooner and with fewer defects if you put in all kinds
of code that doesn't need to be there. Waterfalls are fun.
Why does "Waterfall" add unneeded behavior? The same forces which
create "unnecessary" features in "Waterfall" create those same features
in XP. The C3 project is a prime example.
7) Collective code ownership. The problem is that with everyone fixing
other people's bugs and nobody becoming a bottleneck, you run out of
excuses for delays.
And collective code ownership means that everybody can avoid the nasty
part of the code that's annoying, complicated, and error prone. Been
there, done that, have the scars. Collective code ownership only works
when everybody shares responsibility. XP has no magic which makes this
happen more easily over any other methodology.
8) Small incremental releases. Again, this takes a lot of the fun
surprises out of the release process. Waterfalls are fun.
And how often do you do those? If creating a release takes 2 weeks to
integrate and roll out, then weekly iterations means that 33% of your
time is development and 66% is rollout. Not particularly productive.
You know, most open source projects seem to think that quarterly
releases is as fined grained as they can be, most seem to sit around 6-9
months. XP doesn't seem to have convinced these folks very much.
Yeah, that's all unproven bunk dreamed up by the XP folks. Fortunately
nobody else buys in to that bunk.
There are always fools willing to buy into the latest fad. Fortunately,
the XP fad has waned and right-thinking folk are demanding some proof
before committing their company to such a risky, unproven process.
</sarcasm>
The XP guys specifically talk about what to expect will go wrong if you
drop different bits of the process. Hard to blame them when it turns out
they are right.
Occam's razor suggests that there is a simpler explanation:
XP fails under all circumstances.
The XP folks are the ones making the extraordinary claims. They are the
ones who need to provide the extraordinary proof.
You might want to be careful about that simile. Makes me think about the
similarities between your "they didn't overcome all the project's
obstacles, so they whole methodology is bunk" and ID's curious
"falsification" arguments. ;-)
They had two projects. Both blew up. Either the fault is with XP or it
is not. If it is not the fault of XP, then the fault is also not with
whatever process was used *before* XP.
You can't claim that XP is a success yet the project failed and then
claim that Waterfall/Ad-Hoc/Whatever is a failure because the project
failed. And you don't get to change your definition of "success"
ex-post facto.
Let's see some projects that XP actually saved.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
