>C3 was widely promoted as a tremendous success. the more
>i investigate, the more information comes up that indicates
>that C3 does not differ much from dozens or hundreds of
>other software development projects, with the exception of its
What you mean is, it was not any more successful than dozens
or hundreds of other software development projects. That is
probably true. But C3 was different. Other projects didn't
use pair programming. No other project took simple design
to such an extreme and relied on refactoring to get out of
the corners it puts you in. (Actually, I'm trying to think of other
practices that are unique to XP and can't think of any. And
there are some groups that use pair programming some of the time.)
Other projects weren't following a set of rules dreamed up by Kent.
From Kent's point of view, this project was the one that showed
him that he had hit upon the right set of rules.
C3 is important because that was where Kent figured out XP
and where Ron got turned on to it. But it doesn't prove XP.
No single project proves much of anything. XP will succeed
only if people try it and think it works for them.
So, the IEEE article published after the thesis differed
from the thesis. The language was changed to make the
points more strongly. As long as what was said was true,
this is good, not bad. I expect an article published from
a thesis to be improved. An author is lazy if he just
cuts his thesis into pieces and publishes the pieces.
XP web pages got updated without telling you. I am not
sure what the problem is here. That they are changing
their story? I expect all methodologists to keep
changing their story, because no methodology is perfect.
It would be more of a problem if they did NOT change
their story. That they didn't tell you when they changed
their web pages? Come on!
The XP view of testing is not viewed as adequate by testing experts.
Lots of aspects of XP are not viewed as adequate by someone. The
XP people will either make them adequate, show that they are already
adequate, or figure out when they are adequate and when they are not.
Or admit defeat. But that doesn't seem likely. :-)
I've seen a bunch of methodologies arise. They follow a common
pattern, with RUP being an exception, but OMT and Booch's
original one following the pattern. There is a good designer
who builds stuff that works, and wonders why other people don't.
So, he starts helping other people build systems. Some things
work, some don't. Eventually he hits on a set of things to tell
people that help them to build systems that work, too. He is
thrilled! He has discovered the secret of developing software!
So, he writes a book and goes out to tell the world of his great
discovery. The world has a tendency not to listen. The book is
liked by some people, and disliked by others. He gives tutorials
at conferences, gathers a following, writes magazine articles.
He keeps improving his shpiel, and eventually the book is out of
date. Time for a second edition! Actually, by this time probably
he is on to other things. XP follows this pattern.
The difference between XP and other methodologies is that it is
much more public. We know about the projects that gave rise to
it. We can see it change as the authors both learn how to tell
their story better, and learn a better story. Kent also got a
lot of other people to help him tell his story, so we get to see
a kind of hidden debate between the authors. XP is an
"internet" methodology because it was developed on the internet
and spread by the internet. But the development of XP really
wasn't that different from the development of other methodologies.
In contrast, RUP was an industrial project. Rational wanted to
sell a methodology, so they hired a bunch of methodologists to
develop one. And the Crystal families of methodologies are
different, too. Alistair*burn is not so much a designer
as an anthropologist. But XP was developed like the others.
I like XP because it is a constrast to the earlier OO methodologies.
It is light on pictures. It emphasizes refactoring. (Which I like,
because I've been studying refactoring for over 12 years) It is
fairly small, and easy to teach. It seems to work reasonably well.
I do NOT think it is the end-all and be-all of methodologies, that
everybody should use it, or even that I will use it on my
next project. Though I might. I expect that there will be a much
better methodology in ten years that is based on it, but with a
less objectionable name.
All this is an answer to your question about the honesty of Kent
and company. I am convinced that they invented XP because they
were trying to find a better way of developing software, and
that they honestly think it is a better way. They are not doing
it for the money, though they (like we all) have to make a living
and being the experts of a new methodology helps a lot. On the
other hand, once people learn a particular way of doing something
and start to advocate a particular position, it becomes harder for
them to see the other side of things. This is just as true for
them as for you. So, sometimes it is hard for them to see the
problems that others have with XP. But they expect to keep making
XP better and are constantly trying new things. I think that is
good, though you seem to think it is bad.
Every methodologist I know thinks his methodology is suitable for
all kinds of problems. In reality, each one is good for some particular
kind of problem. It is very hard to figure out what a methodology
is good for, and very hard to figure out what methodology is best
for a particular problem. Michael Jackson (author of the Jackson
Design Method of the 80's) was the first person I saw actually
explain what his methodology was good for, and it was at least 10
years after he invented it.
One of the things I like about XP is that they admit it isn't good
for every project. Now, they almost certainly think it is suitable
for a wider range of projects than it actually is, and it is hard to
pin them down to exactly what its limitations are, but that is to
be expected. The very fact that they are willing to discuss the
limits of XP puts them ahead of most methodologists.
Methodology is not an academic discipline. There are some
academics who study methodology, but the people who make
methodologies that people actually use are usually not academics.
So, it is futile to demand that they adhere to academic standards of
rigor. They are trying to be useful, not rigorous. (Academics, on the
other hand, ...) Of course, when they publish papers, they have
to live up to those standards. It is quite reasonable to expect
Williams to live up to academic standards in her writings. She is
an academic studying XP. It isn't reasonable to expect Beck and Jeffries
to do so. They have a different purpose in life. Truth and honesty
are still important, of course, but I expect them to be less objective.
They are out to save the world from bad software development processes!