Andrew Lentvorski wrote:
Christopher Smith wrote:
First, the leaders are all a bunch of *FAILURES*.
Sorry, that's just wrong. The leaders of XP (Kent Beck, Ward
Cunningham, Ron Jeffries and perhaps you want to throw in Martin
Fowler) were all very successful even prior to the genesis of XP.
Okay, back that statement up with some facts, please. IIRC, Beck was
the only one who accomplished anything useful before XP.
/me falls out of chair.
I'm not sure if you are deliberately being obtuse or you just don't
know. Let's try to throw this one out the door as quickly as possible:
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?
All of these guys were big heavies in the software development community
in general, and the OOP and Design Patterns communities in particular
(Ward actually chaired the first PLoP conference). Ron and Martin are
the ones I remember as having the particularly long and impressive
pedigree of projects to draw upon for their OOPSLA and PLoP
presentations. The best of Martin's pre-XP work is catalogued in
Analysis Patterns (worth reading even if you think patterns are complete
bunk). These guys were all the big guns you brought in if your project
was seriously borked.
The CCC project that spawned all these Smalltalk weenies who
advocate XP got shitcanned. Somehow people don't seem to notice
this. I don't want advice from someone who failed at what they are
giving advice on, thanks.
A project getting canceled doesn't necessarily mean those involved in
it or their methodologies were failures.
Yes, actually, it does. Failed projects are the result of bad
decisions. Given that they led the project, they failed.
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. That
said, they did identify some problems/mistakes they had in the process,
and refined XP based on that experience. That's generally how
methodologies emerge and evolve in the first place.
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? I could use
that about now. I'm sorry, but a lot of the time the business side of
things trumps whatever is going on with the technical side.
I'm not suggesting that they should be branded pariahs and never heard
from again. However, the project they led with their own processes
failed. A failed project does not confer authority (actually, a
successful one only confers very *limited* authority, but that's a
debate for another day).
Okay, so a failed project doesn't confer authority, and a successful one
confers very limited authority. This kind of brings us back to the point
that whether the project was a success or not doesn't really convey much
one way or the other?
In addition, according to "XP Considered Harmful" not only was the
first XP project canceled but also the second one was also canceled:
http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf
Check out the details though. The VCAPS system initially wasn't an XP
project either. In fact, it had languished for 3 years of development
that employed a variant of the waterfall process, with little to show
for it (supposedly they didn't have a single regression test for the
code anywhere). It was plagued with problems and bugs, etc. Everyone was
pissed. In 6 months they managed to dramatically cut the bug count down
and in a year the system was running very smoothly and customers were
very happy. The project wasn't canceled, but placed in maintainence
mode, because the systems that fed in to it had been deemed obsolete and
so, as a by product, was VCAPS (I'm sure you'll find some way to say
that this was all because of shortcomings in XP without actually
describing a causal link, but by most any reasonable person's
definition, this is exactly how projects die for reasons that have
nothing to do about how well the project was executed). Here's the real
wrinkle though: in the end VCAPS was kept in production for another
decade, as the replacement system had difficulty matching its
capabilities and reliability.
Projects get canceled for a lot of reasons, sometimes due to failure
by the development team, but sometimes independent of the success or
failure of the team. In the CCC project's case, the purchase of
Chrystler by Daimler-Benz played a significant role in the project's
demise, not to mention the fact that the project was a fixed-price
contract job that was already behind schedule and over budget (think
of the success rate of projects once they are in that state) before
Beck showed up and started introducing XP practices.
http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System
The XP bunch had *4 years* to get a *payroll* program working before the
Daimler-Chrysler thing. This is something that companies had been doing
for years in COBOL. This isn't rocket science. It is straightforward,
linear decision code.
It was a payroll program. The inputs were specified. The outputs were
specified. They had previously working programs to compare
against--*and they still couldn't deliver*.
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). They
accomplished this despite reducing staffing for the project
significantly while observing significant increases in productivity. The
original project timeline called for *4 years*, which indicates they
were either completely insane or perhaps the project was more complex
than your simplified description. Somewhere in the second year of Beck's
work, they ran in to a problem, as the on site customer was replaced and
the new one who for whatever reason wanted to focus on adding new
features to the system rather than getting everyone on to the new
system. This turned out to be a huge problem because the IT folks who
were actually funding the project had the exact opposite set of
priorities. In XP circles this is referred to as the "GoldOwner" and the
"GoldDonor" not being on the same page. XP practitioners are not alone
in the belief that as long as this conflict exists the project is
doomed. Beck does take the blame for not recognizing the problem as
quickly as he should have, and consequently folks are warned to be
vigilant for this particular problem.
I've worked on several "get it off the mainframe" projects, and they are
anything but as simple as you describe. First of all, there usually is a
whole host of new features that are wanted (typically built up over time
as the mainframe system is highly inflexible, and part of the sell job
of "getting off the mainframe" is increased flexibility). Then there's
the performance constraints. Part of the sell job of getting off the
mainframe is reduced hardware costs, which means you often lack much of
the raw performance of the old system (though you do tend to end up with
a raw CPU performance advantage). If you're unlikely (as I've been), the
mainframe code has some idiosyncratic arithmetic brought about by odd
word sizes and funny little tricks with the FPUs... and they want you to
emulate all the errors that work in their favor, but fix all the ones
that don't. Then there's the real kicker: you often find out that you
aren't just replacing one system, but rather several distinct systems,
each with their own conflicting business logic, and the client
inevitably wants you to unify all these distinct systems... with no idea
how to resolve the logic conflicts.
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.
XP is based on well established principles in the software business.
Not, it's not. There is *zero* data to support most of the assertions
that the XP bunch make.
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>
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.
2) Acceptance tests for representing customer requirements and
validating that you are making those requirements. Can't find a
contractor who likes that.
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.
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.
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.
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.
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.
8) Small incremental releases. Again, this takes a lot of the fun
surprises out of the release process. Waterfalls are fun.
Yeah, that's all unproven bunk dreamed up by the XP folks. Fortunately
nobody else buys in to that bunk.
</sarcasm>
And, when you try to inject data, you are met
with "Well, you aren't *really* doing XP unless you are doing everything
together."
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.
Arguing with XP advocates is like arguing with intelligent design
advocates. They don't get that there is this little thing called
"evidence" that some of us demand.
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. ;-)
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
