Some conclusions regarding XP
ma...@sandbridgetech.com
After looking around at XP, I have come to some conclusions:
XP (probably) works very well when developing
1. programs under 60klocs/year
2. teams containing skewed towards novices/juniors
3. business applications (data-processing, UI et.al.)
4. reasonably mutating specs.
5. moderate correctness requirements
6. (only weakly connected) OO oriented development
XP has several nice practices that initially help programmer development
1. the emphasis on testing
2. pairing (for teaching purposes)
XP will end up inhibiting programmer development, possibly within 1 to 2
years for motivated programmers.
1. The kinds of environments XP is (in my opinion) suited for, and (my
guess) deployed will not stress programmers.
2. The smaller program sizes XP is dealing with also do not impose the
kinds of stresses that help programmers grow.
2. Pair programming prevents programmers from making the kinds of
mistakes that will force them to learn the hard way [note: this is very
good for productivity, but not so good for programmer development]
[An exercise to the reader: ask yourself
- Do I want to write things like the Linux kernel? Apache web server?
gcc compiler? Warcraft III? Quake?
- Can I currently write programs of this kind?
- Will XP give me the programming ability to do so?
]
:)
Mayan
Phlip
> After looking around at XP, I have come to some conclusions:
>
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
Citation?
My team (of 5) is around 200 KLOCs >refactored< per year.
But we cannot stress enough what a terrible metric KLOC is. Make an effort
to ignore it. The map between KLOC refactored and KLOC added is entirely
domain-specific.
The upper bounds of team size, or project size, are unexplored. XP's
existing projects average a size around the same as the industry average
due to penetration, not any scaling problems.
> 2. teams containing skewed towards novices/juniors
Citation?
My team contains mostly seasoned seniors. We are hankering for a better
mix; at which time those novices will get proficient very, very quickly. We
have seen this happen before.
Our most senior coders happen to also be the ones who have been pairing
since before it had a name, and they know much better than to abandon the
process.
A team with a few seniors and many juniors would be ideal for most spaces,
because the communication and feedback spreads the effects of the seniors
around so well.
A team full of only juniors is a recipe for disaster. If you can find a way
around that you'd be a trillionaire.
> 3. business applications (data-processing, UI et.al.)
Citation?
My team is doing raw computer-science research. Our shelves contain old
books full of "documentation" by the BDUF teams who went before us trying
and failing to start what we are now finishing.
> 4. reasonably mutating specs.
Citation?
Our specs have been carved in stone for about 20 years.
Design is the process of resolving conflicting requirements. The order you
do them, or whether future requirements rescind past ones, is irrelevant.
The two ways to design are heroically, or incrementally. XP forces a high
level of incrementalism. The Easy way.
The fact that this incrementalism also lets the OnsiteCustomer steer
towards a business goal is just a happy by-product. Teams typically
progress unaware of steering. The common feeling on the C3 team was "if
someone slipped an air-traffic control user story in amid these paycheck
business rules, we'd just type it in and keep going."
> 5. moderate correctness requirements
Citation?
This is the most erroneous of your assertions. There is nothing anti-XP
about crypto, security, aerospace, high-energy, or medical software. XP
does not mean you sack your QA team to save a buck. In these spaces, the
majority of the user stories will be requests to force a formal
verification, such as path coverage analysis, out of the code base.
> 6. (only weakly connected) OO oriented development
Citation?
Here's UB on comp.object: "I think Test Driven Development is one way to
tell whether you need OO. Very often the solutions I come up with are not
OO (at least not in the small). When an OO solution does come up, it is
often the tests that have driven me to put the abstractions in place."
> XP has several nice practices that initially help programmer development
> 1. the emphasis on testing
> 2. pairing (for teaching purposes)
People always learn. But pairing is primarily about extremely rapid
progress:
http://c2.com/cgi/wiki?BasketballMetaphor
> XP will end up inhibiting programmer development, possibly within 1 to 2
> years for motivated programmers.
Absolute bunk.^H^H Citation?
Why do you think this???
> 1. The kinds of environments XP is (in my opinion) suited for, and (my
> guess) deployed will not stress programmers.
Citation?
Pair programming is exhausting.
Please consider performing the experiment before reporting the results, huh?
> 2. The smaller program sizes XP is dealing with also do not impose the
> kinds of stresses that help programmers grow.
Per Carl Sagan's Baloney Detection Kit, "If there is a chain of argument,
every link in the chain must work."
You can't go from guessing that XP is for trivial apps (your first 1. line
item) to then guessing that trivial apps will bore programmers.
No matter what your methodology, trivial domain spaces will lead to
off-the-shelf solutions. Installing is hardly developing.
> 2. Pair programming prevents programmers from making the kinds of
> mistakes that will force them to learn the hard way [note: this is very
> good for productivity, but not so good for programmer development]
Uh, okay, lack of "School of Hard Knocks". I suppose one might miss out on
learning the ability to solo, or extensive debugger piloting, or UML
without code.
> [An exercise to the reader: ask yourself
> - Do I want to write things like the Linux kernel? Apache web server?
> gcc compiler? Warcraft III? Quake?
> - Can I currently write programs of this kind?
> - Will XP give me the programming ability to do so?
> ]
What the hell^H^H on earth do you think those programs have in common?
Largeness? Extensive feature sets? Deep market penetration?
One thing they do have in common is relentlessly incremental development.
"Apache", the web server, is named as a play on "A Patchy Server" -
referring to the huge number of patches it absorbed during its inflationary
phase.
I'm certain the first few functions written for many of them look little or
nothing like the functions that generate the equivalent abilities in the
current versions.
--
Phlip
http://www.greencheese.org/LucidScheming
-- Who needs a degree when we have Web e-search engines? --
ma...@sandbridgetech.com
Yes, unlike my other posts, I offer no arguments. This is just a summary
of my conclusions, and you are free to disagree with them.
However, I would like you to consider the last question I asked.
> > [An exercise to the reader: ask yourself
> > - Do I want to write things like the Linux kernel? Apache web server?
> > gcc compiler? Warcraft III? Quake?
> > - Can I currently write programs of this kind?
> > - Will XP give me the programming ability to do so?
> > ]
>
> What the hell^H^H on earth do you think those programs have in common?
> Largeness? Extensive feature sets? Deep market penetration?
They are brutally hard to get right, they have fairly tight performance
requirements, they have algorithms that are both large and complex to
code up. Modularization is more difficult. Testing and verification is
quite a different game in these environments.
You have to be an all-round, productive, skilled programmer to work on
them.
Are you already good enough to play in this arena?
If not, when will you get there?
NOTE: I am not saying that a good programmer/team cannot use XP (or any
methodology under the sun) to develop these kinds of programs. I am just
saying that it is my opinion that _IF_ you work exclusively in an XP
environment, _THEN_ you will become
1. average-good more quickly
2. excellent much more slowly
than working in other environments.
As a matter of fact, working in XP for 1-2 years to learn some
fundamental disciplines and development skills, possibly after a
Comp.Sci. degree, is a *GREAT* way to start. However, after that try
working in an environment where you have to tackle these larger
projects. Or try large solo programs. Or work in the embedded arena on
real-time projects.
Acquire a well-rounded bag of tricks/skill set. Become an all-round
programmer.
Mayan
-----------
A major aside, and one I bring up because it is something to think
about:
Someone at IBM who knew Terry Baker, said this about the success of
Chief Programmer Teams and the New York Times project <parapharsed
slightly>:
"Terry Baker was so good that he would make any methodology look great".
Thats a pretty high standard.
Phlip
> However, I would like you to consider the last question I asked.
I did.
>> > [An exercise to the reader: ask yourself
>> > - Do I want to write things like the Linux kernel? Apache web server?
>> > gcc compiler? Warcraft III? Quake?
>> > - Can I currently write programs of this kind?
>> > - Will XP give me the programming ability to do so?
>> > ]
>>
>> What the hell^H^H on earth do you think those programs have in common?
>> Largeness? Extensive feature sets? Deep market penetration?
>
> They are brutally hard to get right, they have fairly tight performance
> requirements, they have algorithms that are both large and complex to
> code up. Modularization is more difficult. Testing and verification is
> quite a different game in these environments.
Right. And there's nothing about them that's anti-XP.
Per the "every link in the chain must work", you have assumed this entire
list of "problems" with XP, entirely without citations, and then picked
some killer apps that you then propose will show XP failing. Link link link.
> You have to be an all-round, productive, skilled programmer to work on
> them.
Wrong. Someone very good at patching Linux's kernel could be appalling at
user interfaces. (Historically, this explains much of Unix's middle strata.)
TDD provides the ability to Refactor Mercilessly. The latter is an
exceptionally good way to leverage an entire team's ability to partition
things into modules. Any decoupling technique you can think of (Dependency
Inversion Principle, Interface Segregation Principle, Open Closed
Principle, Hierarchical Encapsulation, the Design Patterns, etc.) if you
overlooked it for some part of the code, or if that code changed and the
potential for it emerged, you just fearlessly put it in.
The result is many modules that look very small, containing classes that
look small, containing short methods.
A lot of the projects you listed would have much healthier interiors if
they'd been written in a way that enabled Refactor Mercilessly. Free
Software is a beautiful concept, but it encourages small patches that solve
bugs and add features, not large patches that improve design. A patch that
refactored some cruft out would be huge and would hit many dispersed areas,
so it would be very hard for a lieutenant to approve.
Linux's kernel is very healthy, but I suspect in general one could not say
the above projects have modules that look small.
> Are you already good enough to play in this arena?
> If not, when will you get there?
Is that "you" in the plural? I, in the singular, >am< there.
> NOTE: I am not saying that a good programmer/team cannot use XP (or any
> methodology under the sun) to develop these kinds of programs. I am just
> saying that it is my opinion that _IF_ you work exclusively in an XP
> environment, _THEN_ you will become
> 1. average-good more quickly
> 2. excellent much more slowly
> than working in other environments.
Absolutely wrong. XP teams, by the very nature of adopting a rising
technology early, tend to be those in pursuit of excellence, who thrive on
chaos.
> As a matter of fact, working in XP for 1-2 years to learn some
> fundamental disciplines and development skills, possibly after a
> Comp.Sci. degree, is a *GREAT* way to start. However, after that try
> working in an environment where you have to tackle these larger
> projects. Or try large solo programs. Or work in the embedded arena on
> real-time projects.
The engineers I know experiment instead of making up elaborate results.
> A major aside, and one I bring up because it is something to think
> about:
> Someone at IBM who knew Terry Baker, said this about the success of
> Chief Programmer Teams and the New York Times project <parapharsed
> slightly>:
> "Terry Baker was so good that he would make any methodology look great".
> Thats a pretty high standard.
Chief Programmer Team is the worst, and hardly the place to develop
well-rounded skill sets. Even if you'r the chief.
--
Phlip
http://www.greencheese.org/MakeItSo
-- But all the other programmers were doing it! --
Uncle Bob (Robert C. Martin)
>Yes, unlike my other posts, I offer no arguments. This is just a summary
>of my conclusions, and you are free to disagree with them.
This issue I take with your "conclusions" is that they don't appear to
be based upon experiment or observation. They make a fine hypothesis,
but without experiment and observation they aren't any kind of
conclusion at all.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |
You and I can enjoy the experience of not always seeing
eye-to-eye, but we can also respect each other, even when
you might find some idea of mine totally ludicrous.
-- Richard Riehle
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> On Sun, 08 Sep 2002 11:06:58 -0400, ma...@sandbridgetech.com wrote:
>
> >Yes, unlike my other posts, I offer no arguments. This is just a summary
> >of my conclusions, and you are free to disagree with them.
>
> This issue I take with your "conclusions" is that they don't appear to
> be based upon experiment or observation. They make a fine hypothesis,
> but without experiment and observation they aren't any kind of
> conclusion at all.
Ah, okay - call it my opinion instead :)
Like I said feel free to disagree with me; I'm not trying (really hard)
to convince anyone of anything about XP.
In retrospect, the only thing I feel somewhat strongly about - that XP,
like any methodology, eventually morphs from a support to a crutch - is
not going to make a big difference to its intended audience. Programmers
who are good but want to be better will realize sooner or later that its
time to try something different. And they will take a solid grounding in
decent practices with them. Hopefully, once they learn why certain rules
were created, and when they should be broken, they will still use some
of XP's practices. But, it is unlikely that the process they adopt will
always be XP - or even something resembling XP.
Mayan
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > However, I would like you to consider the last question I asked.
Perhaps I should rephrase the questions:
- are you as good a programmer as you can be?
- will XP get you all the way there?
What is your answer?
Mayan
Phlip
> Perhaps I should rephrase the questions:
> - are you as good a programmer as you can be?
> - will XP get you all the way there?
Okay. No, and no.
But having seen XP morph from a support into wings, I have no doubt that
the most advanced things I will do in my career will involve The Twelve
Practices.
I'm quite curious see what new things it will also involve.
--
Phlip
http://c2.com/cgi/wiki?SheChangeDesignInTheDatabase
-- Founding member of NuGWa -
Nudists for Global Warming --
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > However, I would like you to consider the last question I asked.
>
> I did.
>
> >> > [An exercise to the reader: ask yourself
> >> > - Do I want to write things like the Linux kernel? Apache web server?
> >> > gcc compiler? Warcraft III? Quake?
> >> > - Can I currently write programs of this kind?
> >> > - Will XP give me the programming ability to do so?
> >> > ]
> >>
> >> What the hell^H^H on earth do you think those programs have in common?
> >> Largeness? Extensive feature sets? Deep market penetration?
> >
> > They are brutally hard to get right, they have fairly tight performance
> > requirements, they have algorithms that are both large and complex to
> > code up. Modularization is more difficult. Testing and verification is
> > quite a different game in these environments.
> Right. And there's nothing about them that's anti-XP.
Agreed. Absolutely. This isn't about XP or not-XP. This is about the
programmers that work on them. They have a certain expertise level. If
they choose to use XP, or some subset of XP, or some other process which
involves XP, it is because they have the knowledge of a lot of practices
_other_than_XP_, and the wisdom to pick the ones that fit the task.
The originators of XP, and the senior programmers who use XP will also
have followed the same path - they probably know a lot of other
practices than those embodied within XP, and then they winnowed them
down to fit a general populace of programmers and the most common
programs they write.
A novice does not know all the alternatives available. He/she does not
know why and when not to use a certain rule.
>
> Per the "every link in the chain must work", you have assumed this entire
> list of "problems" with XP, entirely without citations, and then picked
> some killer apps that you then propose will show XP failing. Link link link.
>
> > You have to be an all-round, productive, skilled programmer to work on
> > them.
>
> Wrong. Someone very good at patching Linux's kernel could be appalling at
> user interfaces. (Historically, this explains much of Unix's middle strata.)
Absolutely possible. However, wouldn't a programmer who is capable of
doing both a better programmer?
> TDD provides the ability to Refactor Mercilessly. The latter is an
> exceptionally good way to leverage an entire team's ability to partition
> things into modules. Any decoupling technique you can think of (Dependency
> Inversion Principle, Interface Segregation Principle, Open Closed
> Principle, Hierarchical Encapsulation, the Design Patterns, etc.) if you
> overlooked it for some part of the code, or if that code changed and the
> potential for it emerged, you just fearlessly put it in.
>
> The result is many modules that look very small, containing classes that
> look small, containing short methods.
:) Anyone who thinks its possible to write an OS kernel that way, has
never really looked at the problem. This is an easy way of getting
disastrous performance. I would suggest looking at OSF and what they had
to do get it to perform even reasonably.
What are the performance implications of OO? What is the difference in
run-time performance between a function call, a statically bound virtual
function call (C++ virtual functions) and a dynamically bound virtual
function call (Smalltalk, I think)? Do you know why there is a
difference?
99% of the time, and 99% of programmers don't need to know the answer to
these questions. However, the extent to which you are aware of all these
details will determine how complete and versatile a programmer you are.
> A lot of the projects you listed would have much healthier interiors if
> they'd been written in a way that enabled Refactor Mercilessly. Free
> Software is a beautiful concept, but it encourages small patches that solve
> bugs and add features, not large patches that improve design. A patch that
> refactored some cruft out would be huge and would hit many dispersed areas,
> so it would be very hard for a lieutenant to approve.
Note that gcc has undergone 2 complete rewrites [at least]. Things did
get cleaned up. The most recent rewrite was a couple years ago. A
question - do you know why they implemented it the way they did? Is it
different than the way you would have done it? Why might they have
picked a different approach than yours?
> Linux's kernel is very healthy, but I suspect in general one could not say
> the above projects have modules that look small.
>
> > Are you already good enough to play in this arena?
> > If not, when will you get there?
>
> Is that "you" in the plural? I, in the singular, >am< there.
:) What are you working on?
BTW: this is a somewhat personal note [and it _does_ look like a
personal attack but please believe that I am not using ad hominem],
based on your previous notes, you aren't; among other things you seem to
be light in your knowledge of algorithms, and in your systems
programming experience. Of course, I could very easily be wrong - a
stream of Usenet articles is not a good foundantion on which to make a
judgement.
> > NOTE: I am not saying that a good programmer/team cannot use XP (or any
> > methodology under the sun) to develop these kinds of programs. I am just
> > saying that it is my opinion that _IF_ you work exclusively in an XP
> > environment, _THEN_ you will become
> > 1. average-good more quickly
> > 2. excellent much more slowly
> > than working in other environments.
>
> Absolutely wrong. XP teams, by the very nature of adopting a rising
> technology early, tend to be those in pursuit of excellence, who thrive on
> chaos.
<grin> I kind of like that.
> > As a matter of fact, working in XP for 1-2 years to learn some
> > fundamental disciplines and development skills, possibly after a
> > Comp.Sci. degree, is a *GREAT* way to start. However, after that try
> > working in an environment where you have to tackle these larger
> > projects. Or try large solo programs. Or work in the embedded arena on
> > real-time projects.
>
> The engineers I know experiment instead of making up elaborate results.
>
> > A major aside, and one I bring up because it is something to think
> > about:
> > Someone at IBM who knew Terry Baker, said this about the success of
> > Chief Programmer Teams and the New York Times project <parapharsed
> > slightly>:
> > "Terry Baker was so good that he would make any methodology look great".
> > Thats a pretty high standard.
>
> Chief Programmer Team is the worst, and hardly the place to develop
> well-rounded skill sets. Even if you'r the chief.
I absolutely agree. I don't like the CPT idea. However, the question
was: are you good enough to take a methodology - any methodology - and
make it look good?
Mayan
----
I'm into stories these days :) As long as no one really reads too much
into it, here is a Zen parable <as best as I can remember it>:
A student comes to the master, and asks to be led to enlightenment. So,
the master takes him outdoors and sits him down.
"What do you see?" he asks
"I see a mountain with some trees and a stream" replies the student
The master leaves. Several years later he comes back, and asks the
student to tell him what he sees. The student goes into a long
narrative, describing the individual rocks on the mountain, the leaves
on the trees, the course of the stream, the way it sounds, etc.
The master leaves. After several years, he comes back, and asks the
student:
"What do you see?"
"I see a mountain with some trees and a stream"
Phlip
ma...@sandbridgetech.com wrote:
> The originators of XP, and the senior programmers who use XP will also
> have followed the same path - they probably know a lot of other
> practices than those embodied within XP, and then they winnowed them
> down to fit a general populace of programmers and the most common
> programs they write.
The early leaders of the OO movement had a long struggle to codify what
they were doing. Just adding OO abilities to languages and publishing these
was not enough, because newbies still use these languages poorly, causing
problems instead of solving them.
Design Patterns, and then XP, represent the next wave of codification. In
the olden days, these natural geniuses did not say "pairing" or
"test-first"; they just did them, and they did not know how to describe
their lifecycles to newbies in ways that were safe to transcribe.
When the OO movement acquired a second tier, full of programmer/authors,
then the codification began.
>> Wrong. Someone very good at patching Linux's kernel could be appalling at
>> user interfaces. (Historically, this explains much of Unix's middle
>> strata.)
>
> Absolutely possible. However, wouldn't a programmer who is capable of
> doing both a better programmer?
Thank you. <blushing>
>> The result is many modules that look very small, containing classes that
>> look small, containing short methods.
>
> :) Anyone who thinks its possible to write an OS kernel that way, has
> never really looked at the problem. This is an easy way of getting
> disastrous performance. I would suggest looking at OSF and what they had
> to do get it to perform even reasonably.
I held up Linux as the good example among the bad here.
> What are the performance implications of OO?
Ouch. Another thread. Make it right, then make it fast. OO >means< "easily
changed code", so tuning is just changing.
> 99% of the time, and 99% of programmers don't need to know the answer to
> these questions. However, the extent to which you are aware of all these
> details will determine how complete and versatile a programmer you are.
Right. XP is orthogonal here.
> A
> question - do you know why [g++] implemented it the way they did? Is it
> different than the way you would have done it? Why might they have
> picked a different approach than yours?
Sorry. I'm contracting here. I'm sure we can find plenty of my bad examples
in Free Software land.
> :) What are you working on?
>
> BTW: this is a somewhat personal note [and it _does_ look like a
> personal attack but please believe that I am not using ad hominem],
> based on your previous notes, you aren't; among other things you seem to
> be light in your knowledge of algorithms, and in your systems
> programming experience. Of course, I could very easily be wrong - a
> stream of Usenet articles is not a good foundantion on which to make a
> judgement.
Oh, thank you. I'm sure you are familiar with the acronym NDA.
I'm helping to invent a new kind of computer. Lots of algorithms, systems
programming, etc.
Being good at algorithms (not saying I am) is not the same thing as being
able to write about them or lecture online about them.
> I absolutely agree. I don't like the CPT idea. However, the question
> was: are you good enough to take a methodology - any methodology - and
> make it look good?
Yes, but only so good.
> "I see a mountain with some trees and a stream"
--
Phlip
http://www.greencheese.org/LucidScheming
-- My opinions are those of your employer --
John Roth
"Phlip" <phli...@yahoo.com> wrote in message
news:KFKe9.381$ct....@newssvr19.news.prodigy.com...
> ma...@sandbridgetech.com wrote:
>
>
> > A major aside, and one I bring up because it is something to think
> > about:
> > Someone at IBM who knew Terry Baker, said this about the success of
> > Chief Programmer Teams and the New York Times project <parapharsed
> > slightly>:
> > "Terry Baker was so good that he would make any methodology look
great".
> > Thats a pretty high standard.
>
> Chief Programmer Team is the worst, and hardly the place to develop
> well-rounded skill sets. Even if you'r the chief.
As I've said before, and I'll probably say again, the scenery is
littered
with the corpses of methodologies that worked for very exceptional
individuals. Most of them fail when the more average people that are the
mainstay of any profession attempt to put them into practice.
CPT is one such methodology. So far XP does not appear to
be in that class.
John Roth
John Roth
<ma...@sandbridgetech.com> wrote in message
news:3D7B95D8...@sandbridgetech.com...
>
>
> Phlip wrote:
> >
> > Chief Programmer Team is the worst, and hardly the place to develop
> > well-rounded skill sets. Even if you'r the chief.
>
> I absolutely agree. I don't like the CPT idea. However, the question
> was: are you good enough to take a methodology - any methodology - and
> make it look good?
Not being a masochist, and not having anything to prove, I have no
intention of
trying to make a terminally stupid idea look good.
John Roth
>
> Mayan
>
> ----
>
> I'm into stories these days :) As long as no one really reads too much
> into it, here is a Zen parable <as best as I can remember it>:
> A student comes to the master, and asks to be led to enlightenment.
So,
> the master takes him outdoors and sits him down.
> "What do you see?" he asks
> "I see a mountain with some trees and a stream" replies the student
> The master leaves. Several years later he comes back, and asks the
> student to tell him what he sees. The student goes into a long
> narrative, describing the individual rocks on the mountain, the leaves
> on the trees, the course of the stream, the way it sounds, etc.
> The master leaves. After several years, he comes back, and asks the
> student:
> "What do you see?"
> "I see a mountain with some trees and a stream"
That's not quite the way I remember the story, but then, I suppose
there are multiple variants out there. It's a story about the interior
of the
learning process. Presumably, after it is all over, the student can
describe
the details much better than he could at the beginning, but feels no
particular need to dwell on them.
JR.
Uncle Bob (Robert C. Martin)
I completely agree with this -- though it is a far cry from your
previous statement.
>- or even something resembling XP.
I don't know about this last one. Maybe, maybe not. Time will tell.
krasicki
characters on Saturday Night Live. When confronted by a hero, they
wave their hands in respect and say, "I am not worthy."
You have done a wonderful service in the dialogues you've participated
in. Although in a subsequent thread you defer to calling the
following 'opinions', I am inclined to think that they are very close
to being rules-of-thumb for determining the Agile methodology value to
programmers and to companies investigating the genre.
I add my own observations, opinions, and comments because I have been
wrestling with many of these same issues for many months and this
seems a great point of closure for some of the issues.
ma...@sandbridgetech.com wrote in message news:<3D7AD16E...@sandbridgetech.com>...
> After looking around at XP, I have come to some conclusions:
>
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
I would add also projects of that scale that favor and accomodate
rapid application development techniques.
> 2. teams containing skewed towards novices/juniors
Or cheap labor.
XP is a very image conscious phenomenon. Much of the early rhetoric
has faded and using newsgroups as feedback loops it has tightened its
vocabulary and appeal to individuals predispositioned to cults,
exclusivity litmus testing, and so on. It fancies itself *new* and
fashionable, a bias that appeals to youth.
It also is predisposed to very loosey-goosey environments where
egalitarian sentiments can be coupled with modular, one-room, open,
no-privacy working spaces.
It is also predisposed to environments willing to short-circuit
existing checks and balances between abstraction specialists
[architects, designers, BAs], coders, and QA.
It also appeals to environments who want to streamline personnel costs
at any cost. It may accelerate the stream of programming jobs
elsewhere no matter who you are. Because the cost-benefit of pair
programming has not been definitively proven, common sense dictates
that hiring two programmers for the price of one elsewhere solves the
equation.
Under pair programming guidelines, licensed software purchases may be
cut by 50% in participating environments weakening even the software
factory's economics.
> 3. business applications (data-processing, UI et.al.)
I might interject that the bias might be toward new projects and in
environments where the programming staff is given a litmus test -
conform or exit. Senior staff would likely be shown the door or pair
program.
> 4. reasonably mutating specs.
Agreed. And less likely in maintenance environments.
> 5. moderate correctness requirements
The bias being toward architectures that are in place, frameworks
decided, generally homogenous systems, few rough edges or surprises.
> 6. (only weakly connected) OO oriented development
Agreed.
>
> XP has several nice practices that initially help programmer development
> 1. the emphasis on testing
I disagree somewhat here. Appropriate testing should be an emphasis
in all development methodologies. It is commendable that XP recommends
it. It is questionable whether TDD is a healthy way to proceed.
> 2. pairing (for teaching purposes)
Again, every methodology should emphasize collaboration as needed. Xp
is no more exceptional in this regard than programmers who are smart
enough to ask questions of appropriate personnel. One might argue
that important social navigation skills are sacrificed by the
regimented pairings.
>
> XP will end up inhibiting programmer development, possibly within 1 to 2
> years for motivated programmers.
Coupled with TDD, it could be detrimental to understanding the
precepts of programming itself.
> 1. The kinds of environments XP is (in my opinion) suited for, and (my
> guess) deployed will not stress programmers.
> 2. The smaller program sizes XP is dealing with also do not impose the
> kinds of stresses that help programmers grow.
An important and understated point.
> 2. Pair programming prevents programmers from making the kinds of
> mistakes that will force them to learn the hard way [note: this is very
> good for productivity, but not so good for programmer development]
It might promote logic mistakes that will be impossible for the
program authors to comprehend if they know nothing but XP. The
constrained coding world may very well turn into a very real
intellectual flatland.
>
> [An exercise to the reader: ask yourself
> - Do I want to write things like the Linux kernel? Apache web server?
> gcc compiler? Warcraft III? Quake?
> - Can I currently write programs of this kind?
> - Will XP give me the programming ability to do so?
> ]
>
> :)
> Mayan
krasicki: Thanks for the thought experiments.
Kevin Cline
>
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
> 2. teams containing skewed towards novices/junior
I'm wondering what led you to this conclusion.
On the contrary, and like most everything other endeavor,
I think XP works better when the team is highly skilled.
I have done pair programming with other strong developers and found
it incredibly productive and enjoyable. I believe there are
very top-flight programmers who would not enjoy pairing.
The people who resisted pairing seemed to be those whose code
was most in need of refactoring.
Phlip
> You have done a wonderful service in the dialogues you've participated
> in. Although in a subsequent thread you defer to calling the
> following 'opinions', I am inclined to think that they are very close
> to being rules-of-thumb for determining the Agile methodology value to
> programmers and to companies investigating the genre.
Translation: Making things up off the top of your head that agree with
things I made up means more to me than reports of real experience.
--
Phlip
http://www.greencheese.org/LucidScheming
-- Have a :-) day --
David B Lightstone
If you have a citation, it is publically available for review.
Common sense would suggest that citations be provided by the author of the
study, not his alias
"Phlip" <phli...@yahoo.com> wrote in message
news:S2Be9.515$fq5.21...@newssvr15.news.prodigy.com...
David B Lightstone
> krasicki wrote:
>
> > You have done a wonderful service in the dialogues you've participated
> > in. Although in a subsequent thread you defer to calling the
> > following 'opinions', I am inclined to think that they are very close
> > to being rules-of-thumb for determining the Agile methodology value to
> > programmers and to companies investigating the genre.
>
> Translation: Making things up off the top of your head that agree with
> things I made up means more to me than reports of real experience.
If you have learned anything in life Phlip, surely it must have been the
reports are sometimes fabricated.
Here I am not calling you a fabricator, rather I am just observing a long
standing tradition in Science. Claims unsubstanciated with publically
examinable evidence are assumed to be fabrications. Such is the ethos of
Science. The proverbial can you duplicate the results mean just that
identical (within measurable experimental error) conditions and results. It
does not mean similar or any
The experience argument which you present is just a political mechanism
used to disenfranchise those with whom you disagree. By definition
experience which contradicts is usually greated with the remarks:
(1) You are doing something wrong (as opposed to you are doing something
differently)
(2) You are fabricating
(3) You are a troll
nobody does anything according the the ideal of the methodology. Obviously
there are tradeoffs and one must realize their consequences. This by means
of characterization and by means of determining the basis for the selected
tradeoffs.
Finally because problem solving is not a systematic craft (ie TDD can be
interpreted, by me, probably not by you, as an attempt to establish an
systematic problem solving craft) you have to fake it via a post solution
discover activity of reformulation to fit the ideal. At best your TDD is an
element of that reformulation
Tom Plunket
> > [An exercise to the reader: ask yourself
> > - Do I want to write things like the Linux kernel? Apache web server?
> > gcc compiler? Warcraft III? Quake?
> > - Can I currently write programs of this kind?
> > - Will XP give me the programming ability to do so?
> > ]
According to a guy I roundtabled with at the Game Developers'
Conference last May, Blizzard (creators of Warcraft) is doing
extreme programming on some of their projects.
Additionally, there are other game development studios in various
stages of agile adoption scattered around (if the people in this
roundtable weren't lying).
-tom!
John Roth
"Tom Plunket" <to...@fancy.org> wrote in message
news:ljo1ouoh6h1qmo4je...@4ax.com...
Hi tom! Glad to see you back on the ng.
John Roth
>
> -tom!
Tom Adams
> ma...@sandbridgetech.com wrote:
>
> > After looking around at XP, I have come to some conclusions:
> >
> > XP (probably) works very well when developing
> > 1. programs under 60klocs/year
>
> Citation?
>
Philip,
You ask for citations many times in your post. However, you offer
no citations to support your own claims. The only citation that your
post includes is a link to a cartoon site in your signature.
Please practice what you preach.
David B Lightstone
"Tom Adams" <tada...@yahoo.com> wrote in message
news:ea44f5a1.0209...@posting.google.com...
Give him a break, he can't provide citations without revealing his
identity.
Perhaps on day he will have a "friend" post citations in his behalf. Until
then we have the word of Phlip.
Ron Jeffries
>[An exercise to the reader: ask yourself
>- Do I want to write things like the Linux kernel? Apache web server?
>gcc compiler? Warcraft III? Quake?
>- Can I currently write programs of this kind?
>- Will XP give me the programming ability to do so?
My teams and I have written operating systems, relational database systems,
language compilers,graphical display software, applications software of many
kinds, and even a bit of real-time control.
And I have done XP. I would use XP for every one of those kinds of work were I
to do them again.
Have you tried XP yet, mayan? Or are you speculating?
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Ron Jeffries
I hope I'm not as good as I can be, since I've only worked on those things I
listed in another post on this thread and have only programmed, let's see ...
IBM 704/7090/7094/1401/360...
DEC PDP-1/PDP-7/PDP-8
Burroughs E-101 if you think that's programming
SDS 940
Xerox Sigma 7/Sigma 9
Apple ][
Intel from 8080 on.
I've written a lot of programs. I could write any and all of them test-driven.
I'd rather do so. I'd rather do them all pairing. I could now estimate any of
them, deliver them incrementally so that management/business could know what was
going on.
XP will get me anywhere I might need to go. What do you imagine it might not let
you do that you've already done, or that you might want to do?
And ... tell us about the XP projects you've been on, please.
ma...@sandbridgetech.com
Ron Jeffries wrote:
>
> On Sun, 08 Sep 2002 00:26:22 -0400, ma...@sandbridgetech.com wrote:
>
> >[An exercise to the reader: ask yourself
> >- Do I want to write things like the Linux kernel? Apache web server?
> >gcc compiler? Warcraft III? Quake?
> >- Can I currently write programs of this kind?
> >- Will XP give me the programming ability to do so?
>
> My teams and I have written operating systems, relational database systems,
> language compilers,graphical display software, applications software of many
> kinds, and even a bit of real-time control.
And all this was done using XP? I find that hard to believe - VERY hard
to believe. But I would be happy to be proven wrong :)
Are there any specific projects you can mention? Any details? Write-ups?
I'd be particularily interested in hearing about the O.S. and compiler
work that you/your team did using XP.
[Now if you did this using disciplines/methodologies that were *NOT* XP,
but had *SOME* of the practices of XP (or even none of them), now that I
would find believable]
> And I have done XP. I would use XP for every one of those kinds of work were I
> to do them again.
It would depend on the team and the project, for me.
> Have you tried XP yet, mayan? Or are you speculating?
XP - no. Some XP practices - for a long, _LONG_ time.
ma...@sandbridgetech.com
Ron, I think you're missing the point - my claim was that XP would
inhibit programmer development (after a point, probably 1-2 years for a
good programmer). You *personally* have a lot of programming skills. But
I will bet that you picked 90%+ of them up in environments other than
XP.
Now that you have those skills, you may be able to use them effectively
in the context of XP. *BUT*
a) you have other skills/experiences to fall back on.
b) you use them (probably daily) to influence the things you do.
Ron Jeffries wrote:
>
> On Sun, 08 Sep 2002 13:49:09 -0400, ma...@sandbridgetech.com wrote:
>
> >> > However, I would like you to consider the last question I asked.
> >
> >Perhaps I should rephrase the questions:
> >- are you as good a programmer as you can be?
> >- will XP get you all the way there?
> >
> >What is your answer?
>
> I hope I'm not as good as I can be, since I've only worked on those things I
> listed in another post on this thread and have only programmed, let's see
<snipped impressive list of machines>
>
> I've written a lot of programs.
Most of them non-XP
> I could write any and all of them test-driven.
An operating system kernel? An optimizing compiler? For commercial use?
In that case your defition of either TDD or adequate testing differs
considerably from mine. I'd want a seperate, large set of both white and
black box tests written post-facto.
BTW: what team-sizes are you look at?
> I'd rather do so. I'd rather do them all pairing.
O.K.
> I could now estimate any of
> them, deliver them incrementally so that management/business could know what was going on.
Alright lets test thins: here's one:
Goal: develop an optimizing C compiler back-end, with at least the
optimizations to be found in gcc. What is your estimates for:
- man years
- team size
- loc
- test-suite size
> XP will get me anywhere I might need to go. What do you imagine it might not let
> you do that you've already done, or that you might want to do?
Hmm...
- O.S. kernels
- compilers
- avionics software
- any project that is large/complex/mission-critical
> And ... tell us about the XP projects you've been on, please.
None.
Now let me ask - how many medium-to-large XP projects other than the C3
one have you done? (Not provide mentoring for, or consulted on, but
actually programmed on, more-or-less from beginning to end)
:)
Mayan
Phlip
> Ron, I think you're missing the point - my claim was that XP would
> inhibit programmer development (after a point, probably 1-2 years for a
> good programmer).
XP has been around for >5 years, and folks were doing most of its practices
for a decade or so without a name. We've had enough time to collect
evidence regarding any limit to its growth curve. Such data would have come
in the form of a series of Wiki pages, mailing list messages and newsgroup
messages from many 2-year alumni saying, "I got bored with XP and moved on.
Later, folks."
Myself? 3 years and counting. And if you challenge my programming abilities
(by claiming my development is somehow inhibited) I will write code that
bitch-slaps yours into next week. 8-)
--
Phlip
http://www.greencheese.org/AndNowaNitelyLitelyUrbanOne
-- How does Bugs Bunny do it? How does he know when he
wakes up in the morning to put in his pocket 3 sticks
of dynamite, a physician costume, and a bicycle pump? --
David B Lightstone
<ma...@sandbridgetech.com> wrote in message
news:3D83473E...@sandbridgetech.com...
I think that pretty much articulates the experiences of anybody with more
than say 5 years experience in this game.
Somehow, someone, (that's you Ronn), thinks, the only way an individual can
understand the implications of new ideas (or even bad old one) on their
daily activities, is via experimentation. Sorry to upset your apple cart
Ronn, but as long as the extrapolation is not excessive, it can be done.
Human beings have been doing it for a rather long time.
Now if you want to say that the practices of eXtreme programming, are such
that the extrapolation just is not valid. I certainly will not disagree. I
can't speak for those who disagree for the sake of disagreeing. There is
always someboddy who is disagreeable
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > Ron, I think you're missing the point - my claim was that XP would
> > inhibit programmer development (after a point, probably 1-2 years for a
> > good programmer).
>
> XP has been around for >5 years, and folks were doing most of its practices
> for a decade or so without a name. We've had enough time to collect
> evidence regarding any limit to its growth curve. Such data would have come
> in the form of a series of Wiki pages, mailing list messages and newsgroup
> messages from many 2-year alumni saying, "I got bored with XP and moved on.
> Later, folks."
<grin> I haven't seen evidence of any serious project being mounted
using XP either. So they definitely aren't progressing up the complexity
chain either.
About the only claims that I have seen are:
- 200klocs of code for something which is under NDA
[heck, data mining software? on a Linux cluster connected with ATM
switches? Come on - why can't people talk about that in general terms at
least]
- blizzard software is using it for some of their programming.
[Good; can we get any details? Are they using it for their gaming
engine? For their graphics engine? Or something else?]
- "embedded" software environments - still no idea what specifically -
IDEs/BSPs are embedded software environments, and so are device drivers.
> Myself? 3 years and counting. And if you challenge my programming abilities
> (by claiming my development is somehow inhibited) I will write code that
> bitch-slaps yours into next week. 8-)
<grin> ok, ok, you _DO_ have a bigger dick than mine :)
On the other hand - you have no evidence of what my programming
abilities are. They might be a tad bit better than you suspect :)
Mayan
Phlip
> <grin> I haven't seen evidence of any serious project being mounted
> using XP either. So they definitely aren't progressing up the complexity
> chain either.
Speak for yourself.
--
Phlip
http://c2.com/cgi/wiki?SheChangeDesignInTheDatabase
Uncle Bob (Robert C. Martin)
GMT, "David B Lightstone" <david.lightst...@prodigy.net>
might (or might not) have written:
>There is always someboddy who is disagreeable
Agreed.
Uncle Bob (Robert C. Martin)
GMT, "David B Lightstone" <david.lightst...@prodigy.net>
might (or might not) have written:
>Somehow, someone, (that's you Ronn), thinks, the only way an individual can
>understand the implications of new ideas (or even bad old one) on their
>daily activities, is via experimentation. Sorry to upset your apple cart
>Ronn, but as long as the extrapolation is not excessive, it can be done.
>Human beings have been doing it for a rather long time.
Yes, they have. They extrapolated that since feathers fell slower
than rocks, heavy things fall proportionally faster than light things.
That extrapolation lasted two thousand years.
Extrapolation of this kind is called -- guessing. Sometimes it
works, sometimes it doesn't. If you want to *know* something, you
have to do the experiments.
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
>
>
>Phlip wrote:
>>
>> ma...@sandbridgetech.com wrote:
>>
>> > Ron, I think you're missing the point - my claim was that XP would
>> > inhibit programmer development (after a point, probably 1-2 years for a
>> > good programmer).
>>
>> XP has been around for >5 years, and folks were doing most of its practices
>> for a decade or so without a name. We've had enough time to collect
>> evidence regarding any limit to its growth curve. Such data would have come
>> in the form of a series of Wiki pages, mailing list messages and newsgroup
>> messages from many 2-year alumni saying, "I got bored with XP and moved on.
>> Later, folks."
>
><grin> I haven't seen evidence of any serious project being mounted
>using XP either. So they definitely aren't progressing up the complexity
>chain either.
There are *lots* of very serious projects that are currently using XP.
These projects span many different industries and many different
environments. They range from embedded real-time to scientific to
financial, to MIS. The companies using XP range from tiny consulting
shops, to start ups, to Fortune 500 companies in virtually every
field.
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> It is remotely possible that on (or about) Sat, 14 Sep 2002 11:47:32
> -0400, ma...@sandbridgetech.com might (or might not) have written:
>
> >
> >
> >Phlip wrote:
> >>
> >> ma...@sandbridgetech.com wrote:
> >>
> >> > Ron, I think you're missing the point - my claim was that XP would
> >> > inhibit programmer development (after a point, probably 1-2 years for a
> >> > good programmer).
> >>
> >> XP has been around for >5 years, and folks were doing most of its practices
> >> for a decade or so without a name. We've had enough time to collect
> >> evidence regarding any limit to its growth curve. Such data would have come
> >> in the form of a series of Wiki pages, mailing list messages and newsgroup
> >> messages from many 2-year alumni saying, "I got bored with XP and moved on.
> >> Later, folks."
> >
> ><grin> I haven't seen evidence of any serious project being mounted
> >using XP either. So they definitely aren't progressing up the complexity
> >chain either.
>
> There are *lots* of very serious projects that are currently using XP.
> These projects span many different industries and many different
> environments. They range from embedded real-time to scientific to
> financial, to MIS. The companies using XP range from tiny consulting
> shops, to start ups, to Fortune 500 companies in virtually every
> field.
>
Excellent! Are there any names, references etc. that you are free to
give? It would be nice to get some info from the trenches - or even an
idea of what XP is being used for. So far, I haven't gotten any detail
on anything other than the C3 project.
Thanks!
Mayan
David B Lightstone
"Uncle Bob (Robert C. Martin)"
news:mk47ou8646jto1l7h...@4ax.com...
> It is remotely possible that on (or about) Sat, 14 Sep 2002 15:53:08
> GMT, "David B Lightstone" <david.lightst...@prodigy.net>
> might (or might not) have written:
>
> >Somehow, someone, (that's you Ronn), thinks, the only way an individual
can
> >understand the implications of new ideas (or even bad old one) on their
> >daily activities, is via experimentation. Sorry to upset your apple cart
> >Ronn, but as long as the extrapolation is not excessive, it can be done.
> >Human beings have been doing it for a rather long time.
>
> Yes, they have. They extrapolated that since feathers fell slower
> than rocks, heavy things fall proportionally faster than light things.
> That extrapolation lasted two thousand years.
>
> Extrapolation of this kind is called -- guessing. Sometimes it
> works, sometimes it doesn't. If you want to *know* something, you
> have to do the experiments.
Oh, I was hoping we could avoid using such loaded words, guessing ,
judgement, what is the difference?
Anyhow if you need absolute certainty, then you would be paralized with
inaction.
Some people don't need absolute certainty. I suspect that you like to
consider yourself to be one such person.
If you need to determine if you are extrapolating excessively, an
experiment might be useful. Is there any chance that excessive
extrapolation/guessing/judgement will to occur?
I noticed that you snipped the question from the original post. I guess
that means you would prefer that it be ignored.
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
Here's a good place to start, it's an old and incomplete list:
http://c2.com/cgi/wiki?ExtremeProgrammingProjects
Then there's Symantec:
http://www.sdmagazine.com/documents/s=2279/sdm0201a/0201a.htm
Workshare:
http://www3.workshare.com/news/ne_pressreleases_view.asp?pressID=27
Escrow.com, Sabre, Qwest, and loads of others.
Then you can go to the various Job referral web sites like Monster and
do a search for job postings that include Extreme Programming.
Go to the XP/Agile universe web site (http://www.xpuniverse.com/home)
and scan the papers to get some ideas of the companies doing XP. Do
the same for the XP2002, XP2001, and XP2000 sites.
http://www.xp2002.org/prog_full.html
http://ciclamino.dibe.unige.it/xp2000/XP2001.html
http://ciclamino.dibe.unige.it/xp2000/
And keep watch on the XP2003 site:
http://www.xp2003.org
Next, take a look at the Extreme Programming Yahoo Group:
http://groups.yahoo.com/group/extremeprogramming/
And there are a wealth of other resources like that.
There were well over 350 people at XP/Agile Universe this year -- up
by more than 100 over last year. There were many companies
represented there that were doing XP.
Peter Harrison
> Anyhow if you need absolute certainty, then you would be paralized with
> inaction.
> Some people don't need absolute certainty. I suspect that you like to
> consider yourself to be one such person.
>
> If you need to determine if you are extrapolating excessively, an
> experiment might be useful. Is there any chance that excessive
> extrapolation/guessing/judgement will to occur?
The issue here is that there are people actually using Agile principles, and
that the initial propositions have been determined by people using Agile
methods in the real world by experience.
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
In other words it doesn't work on large projects. The assumption here is
that you can't break large projects into smaller sub projects. There is
quite good statitical evidence that larger projects are more prone to
failure, so breaking them up is good practise regardless of methodology.
> 2. teams containing skewed towards novices/juniors
Actually the reverse in my experience. Skilled developers I have worked with
suit pair programming well, and have the discipline. I have found juniors
need to have disipline forced on them to stay in pairs and to write unit
tests. They easily slip into bad habits.
> 3. business applications (data-processing, UI et.al.)
The companies using XP in New Zealand I know of are from all kinds of
industry. One of the best known XP shop is actually a manufacturing control
company.
> 4. reasonably mutating specs.
Perhaps true in theory, although I have never been on a project with perfect
requirements and specifications. In fact static specifications makes the
assumption of perfect requirements definition and a perfect system analysis
and specification. In my experience such a beast is a myth.
> 5. moderate correctness requirements
Are we saying here that a project that has grossly incorrect requriements
can succeed? Clearly having requirements that are at least moderatly
correct is a nessesity regardless of methodology.
6. (only weakly connected) OO oriented development
Agile methods are not really tied to OO at all. Some concepts around
refactoring and testing obviously apply to OO principles better than
structured or functional programming. However I don't think OO is a
requirement when doing XP/Agile.
ma...@sandbridgetech.com
would inhibit programmer development and then asked:
[An exercise to the reader: ask yourself
- Do I want to write things like the Linux kernel? Apache web server?
- Can I currently write programs of this kind?
- Will XP give me the programming ability to do so?
Someone said that XP was being used to do things like this.
I asked for examples.
Robert Martin was kind enough to give me some leads, and I spent some
time following them up.
> >"Uncle Bob (Robert C. Martin)" wrote:
>
> >> There are *lots* of very serious projects that are currently using XP.
> >> These projects span many different industries and many different
> >> environments.
<snip>
> >>
> >
> >Excellent! Are there any names, references etc. that you are free to
> >give? It would be nice to get some info from the trenches - or even an
> >idea of what XP is being used for. So far, I haven't gotten any detail
> >on anything other than the C3 project.
>
Here's a summary of my [incomplete] research.
- only one write up that really got into the war stories [IrrsProject]
- only one company doing something hard [Sparta], and one possible
[Omnigon]
- it is NOT clear that Sparta is using XP _at_all_ or what they are
using it for.
Most companies are doing what I'd call "middle-ware" or "web-ware" for
lack of a better word.
So, I'm still waiting on war-stories or trench-reporting on the use of
XP in hard projects.
Mayan
-----
> Here's a good place to start, it's an old and incomplete list:
> http://c2.com/cgi/wiki?ExtremeProgrammingProjects
OK:
AdrenalineGroup (Washington DC, Austin TX):
- mostly web stuff; servlets, websites, server side Java stuff
- nothing about XP practices/experiences
BabbleNet (Vancouver, Canada)
http://alphaworks.ibm.com/aw.nsf/bios/babblenet
- peer-to-peer chat
- 7 people
- mixed development [not everyone used XP; probably 1/2]
- non-commercial
ChryslerComprehensiveCompensation
- payroll
- XP developed here
- discontinued
CsXpCompanies (Colorado Springs XP Companies)
channelpoint
- web stuff; servlets
- out of business
sparta
- military support stuff; probably fairly sophisticated systems
- nothing about the use of XP
DoIt
- distributed objects [OO+CORBA? Some java thrown in]
- nothing about experiences with XP
EvantSolutions (San Francisco)
- web services [web-based merchandising solutions; middleware]
- nothing about experiences
- CTO (who seemed to be their XP cheerleader) got kicked out
GrainMonitorProject (Boston area)
- mobile spectrometer
- nothing about experiences
- project cancelled
HpSoapProject
IrrsProject
- excellent write up.
- not clear what they were doing
- small project (3 people)
LockheedMartinResearchAndDevelopment -- XP with PowerBuilder 7, even
- not clear what they are up to. [probably middleware].
-
NexMedia -
- out of business
OmnigonInternational - eXtreme like no project ever before or again...
- protein folding/genome searching/financial industry [data mining
apps?]
- were building clusters linked by ATM switches before that.
- no info on their XP experiences
ProductSight
- product development support?
- no mention of XP anywhere on their web site [have they abandoned it?]
No time to go through the rest.
> http://www3.workshare.com/news/ne_pressreleases_view.asp?pressID=27
looked at that; interesting; not very stressful though.
> Go to the XP/Agile universe web site (http://www.xpuniverse.com/home)
> and scan the papers to get some ideas of the companies doing XP
Did; couldn't figure out much - mostly consultants and consulting
houses.
ma...@sandbridgetech.com
Peter Harrison wrote:
> > XP (probably) works very well when developing
> > 1. programs under 60klocs/year
>
> In other words it doesn't work on large projects. The assumption here is
> that you can't break large projects into smaller sub projects. There is
> quite good statitical evidence that larger projects are more prone to
> failure, so breaking them up is good practise regardless of methodology.
Good idea; unfortunately you till have to deal with integration issues.
And some programs are not really amenable to that kind of factoring.
> > 2. teams containing skewed towards novices/juniors
>
> Actually the reverse in my experience. Skilled developers I have worked with
> suit pair programming well, and have the discipline. I have found juniors
> need to have disipline forced on them to stay in pairs and to write unit
> tests. They easily slip into bad habits.
What is your definition of skilled? [Productivity? Design Skills?
Experience?]
> > 3. business applications (data-processing, UI et.al.)
>
> The companies using XP in New Zealand I know of are from all kinds of
> industry. One of the best known XP shop is actually a manufacturing control
> company.
Is there a reference? Do they have some war-stories written up? What do
they do?
> > 4. reasonably mutating specs.
>
> Perhaps true in theory, although I have never been on a project with perfect
> requirements and specifications. In fact static specifications makes the
> assumption of perfect requirements definition and a perfect system analysis
> and specification. In my experience such a beast is a myth.
Agreed. However there is a large variation from - "develop me a web
site, I don't know what it will look like" to "implement the IEEE 802.11
MAC layer"
> > 5. moderate correctness requirements
>
> Are we saying here that a project that has grossly incorrect requriements
> can succeed? Clearly having requirements that are at least moderatly
> correct is a nessesity regardless of methodology.
Correctness in the sense of how much the program has to be tested. Web
app breaks - no biggy; shuttle software breaks - OOPS!
> 6. (only weakly connected) OO oriented development
>
> Agile methods are not really tied to OO at all. Some concepts around
> refactoring and testing obviously apply to OO principles better than
> structured or functional programming. However I don't think OO is a
> requirement when doing XP/Agile.
Agreed.
Mayan
Phlip
> - only one company doing something hard [Sparta], and one possible
> [Omnigon]
> - it is NOT clear that Sparta is using XP _at_all_ or what they are
> using it for.
>
> Most companies are doing what I'd call "middle-ware" or "web-ware" for
> lack of a better word.
Again, most projects in the industry in general do those things.
> So, I'm still waiting on war-stories or trench-reporting on the use of
> XP in hard projects.
Are you familiar with the meaning and purpose of an "NDA"?
--
Phlip
http://www.greencheese.org/PhilosophyBrethrenThree
-- DARE to resist drug-war profiteering --
John McClenny
ma...@sandbridgetech.com says...
> Ron, I think you're missing the point - my claim was that XP would
> inhibit programmer development (after a point, probably 1-2 years for a
> good programmer). You *personally* have a lot of programming skills. But
> I will bet that you picked 90%+ of them up in environments other than
> XP.
I came in late here. I don't understand why you think that getting
exposed to a wide range of programming partners (including the most
senior) as XP can promote would inhibit your development as a programmer?
In what way does working solo improve your skills faster than working
paired?
As a total aside, as a pointy headed manager, I would rather have a group
with higher than average skills than one genius and a bunch of morons :).
The star system has failed miserably in many of the projects I have been
involved in and I find it more important to increase as many peoples
skills as possible. I haven't used XP, but don't understand how a system
that lets me encourage skill sharing and mentoring can be detrimental.
Unless, of course, you just want to maximize your skills relative to your
peers by setting up a system that discourages their improvement :).
Doc
Peter Harrison
> Good idea; unfortunately you till have to deal with integration issues.
> And some programs are not really amenable to that kind of factoring.
The NZ Police tried a big bang straegy and had a rather public failure.
There were various reasons, but ultimatly there is little good reason not
to 'refactor' large projects into smaller chunks. Yes there are intergration
issues, however if you have unit tests you can work these out pretty
quickly.
> What is your definition of skilled? [Productivity? Design Skills?
> Experience?]
"Skilled&