Some conclusions regarding XP

50 views
Skip to first unread message

ma...@sandbridgetech.com

unread,
Sep 8, 2002, 12:26:22 AM9/8/02
to

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

unread,
Sep 8, 2002, 1:16:34 AM9/8/02
to
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?

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

unread,
Sep 8, 2002, 11:06:58 AM9/8/02
to

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

unread,
Sep 8, 2002, 12:12:26 PM9/8/02
to
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.

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)

unread,
Sep 8, 2002, 1:17:50 PM9/8/02
to
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.

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

unread,
Sep 8, 2002, 1:34:07 PM9/8/02
to

"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

unread,
Sep 8, 2002, 1:49:09 PM9/8/02
to

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

unread,
Sep 8, 2002, 2:22:39 PM9/8/02
to
ma...@sandbridgetech.com wrote:

> 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

unread,
Sep 8, 2002, 2:24:24 PM9/8/02
to

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

unread,
Sep 8, 2002, 2:45:53 PM9/8/02
to
[Attempting to contract here]

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

unread,
Sep 8, 2002, 5:43:49 PM9/8/02
to

"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

unread,
Sep 8, 2002, 5:49:25 PM9/8/02
to

<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)

unread,
Sep 8, 2002, 9:53:16 PM9/8/02
to

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

unread,
Sep 8, 2002, 10:59:10 PM9/8/02
to
krasicki: Let me preface my comments by using a phrase that comes from
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

unread,
Sep 8, 2002, 11:15:05 PM9/8/02
to
> 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/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

unread,
Sep 8, 2002, 11:21:45 PM9/8/02
to
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.

--
Phlip
http://www.greencheese.org/LucidScheming
-- Have a :-) day --

David B Lightstone

unread,
Sep 9, 2002, 7:44:16 AM9/9/02
to
Citation don't you mean claim.
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

unread,
Sep 9, 2002, 8:00:34 AM9/9/02
to

"Phlip" <phli...@yahoo.com> wrote in message
news:ctUe9.920$5G4.43...@newssvr15.news.prodigy.com...

> 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

unread,
Sep 12, 2002, 2:55:20 PM9/12/02
to
Phlip 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?
> > ]

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

unread,
Sep 12, 2002, 10:02:14 PM9/12/02
to

"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

unread,
Sep 13, 2002, 8:05:48 AM9/13/02
to
Phlip <phli...@yahoo.com> wrote in message news:<S2Be9.515$fq5.21...@newssvr15.news.prodigy.com>...

> 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

unread,
Sep 13, 2002, 8:39:38 AM9/13/02
to

"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

unread,
Sep 14, 2002, 7:27:55 AM9/14/02
to
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 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

unread,
Sep 14, 2002, 7:35:33 AM9/14/02
to

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

unread,
Sep 14, 2002, 10:27:10 AM9/14/02
to

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

unread,
Sep 14, 2002, 10:49:40 AM9/14/02
to

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

unread,
Sep 14, 2002, 11:19:08 AM9/14/02
to
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."

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

unread,
Sep 14, 2002, 11:53:08 AM9/14/02
to

<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

unread,
Sep 14, 2002, 11:47:32 AM9/14/02
to

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

unread,
Sep 14, 2002, 1:26:06 PM9/14/02
to
ma...@sandbridgetech.com wrote:

> <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)

unread,
Sep 14, 2002, 3:51:36 PM9/14/02
to
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:

>There is always someboddy who is disagreeable

Agreed.

Uncle Bob (Robert C. Martin)

unread,
Sep 14, 2002, 3:51:08 PM9/14/02
to
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.

Uncle Bob (Robert C. Martin)

unread,
Sep 14, 2002, 4:01:09 PM9/14/02
to
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.

ma...@sandbridgetech.com

unread,
Sep 14, 2002, 4:38:43 PM9/14/02
to

"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

unread,
Sep 14, 2002, 5:28:31 PM9/14/02
to

"Uncle Bob (Robert C. Martin)"
<u.n.c.l.e.b.o.b.@.o.b.j.e.c.t.m.e.n.t.o.r.d.o.t.c.o.m> wrote in message
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)

unread,
Sep 14, 2002, 8:33:39 PM9/14/02
to
It is remotely possible that on (or about) Sat, 14 Sep 2002 16:38:43

-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

unread,
Sep 15, 2002, 9:52:09 AM9/15/02
to
David B Lightstone wrote:


> 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

unread,
Sep 14, 2002, 11:19:13 PM9/14/02
to
I would like to restate what started this thread; I had asked whether XP
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?
- gcc compiler? Warcraft III? Quake?

- 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

unread,
Sep 14, 2002, 11:25:49 PM9/14/02
to

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

unread,
Sep 15, 2002, 12:08:23 AM9/15/02
to
ma...@sandbridgetech.com wrote:

> - 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

unread,
Sep 15, 2002, 12:21:10 AM9/15/02
to
In article <3D834C84...@sandbridgetech.com>,
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

unread,
Sep 15, 2002, 12:38:03 PM9/15/02
to
ma...@sandbridgetech.com wrote:

> 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" is a rather subjective thing. Its a bit like quality - you know it
when you see it. In practical terms it means being a competent commercial
developer. You need to know ( and care ) why you format code so others can
read it. You have to be able to communicate.

Juniors are just learning - and usually have these ego problems. They need
these knocked out and some real professional principles instilled. That
usually takes a year or two.

> Is there a reference? Do they have some war-stories written up? What do
> they do?

I'll ask - but generally they are far too busy at the coalface. They arn't
making a big song and dance about XP - they just do it - and very well it
appears.

> 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"

I wish someone would give me a "implement the IEEE..." type spec :-)

> Correctness in the sense of how much the program has to be tested. Web
> app breaks - no biggy; shuttle software breaks - OOPS!

Sorry, my misunderstanding. This is out of my experience. Nothing I have
done is life critical. However, with the concentration on quality and
testing XP would be better than other methods I have used.

Final Thought:

I think its important computer professionals also have more than one way to
skin a cat so they can adapt to new situations. XP has many good ideas, but
I don't think it should be considered the *one true way*. I personally
developed most of the ideas in XP independantly - mostly as a result of
analysis of failed projects. The most important part - as my flying
instructor used to say - is to continue to think and adapt to the changing
circumstances.

Regards,

Peter

Regards,

Peter

krasicki

unread,
Sep 15, 2002, 12:42:29 AM9/15/02
to
ma...@sandbridgetech.com wrote in message news:<3D835A14...@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."

Do you have a count of people who've tried XP and died either of
boredom or OD'ed to death on bad Wiki?

But you say you have alumni? Do they fight over the diploma? Do they
look different before and after? I'm betting they still write, "Never
change" in the yearbooks right - too cute.

>
> <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.

I think the Agile cabal_that_isn't_a_cabal is anxiously waiting their
turn to receive a Darwin dubious extinction award. Anybody who
blindly tries anything based on the flimsy presumptions we get here
will not be progressing up any complexity chains soon.


<snip>

Phlip

unread,
Sep 15, 2002, 12:53:16 AM9/15/02
to
John McClenny wrote:

> 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?

Because it's too easy. To grow, people need hard knocks, and they'l often
deliver these to themselves on purpose.

To grow, teams need easy problems solved one at a time, to keep the rhythm
going.

But my first guess at the nature of this "inhibition" worry is that it's a
turf-building instinct. If I think I can't claim ownership for some module
or process, I'l think I can't score at performance review time.

XP does not have that problem.

Attacks on XP typically target one practice (such as pair programming), by
deliberately forgetting countering practices (such as the practice of
putting all engineers in one room). At performance review time, the team
knows who did what well.

> 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 :).

In my experience (and in that of many others who have actually tried
practices like these instead of making up things about them on the
Internet), XP spreads the effect of the genius out better than Brand X.

And it makes identifying the real morons much more easy than some people
find comfortable.

> 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.

The number one skill XP prizes is the ability to pick the >simplest<
solution for a given problem, meaning the most elegant one with the least
lines of code. Learning, in my experience and others', happens when someone
surprises you with a fix that's actually simpler than the one you'd have
started with. Ouch.

> Unless, of course, you just want to maximize your skills relative to your
> peers by setting up a system that discourages their improvement :).

Quite a lot of this can get ingrained into cultures.

--
Phlip
http://www.greencheese.org/InMildDefenseOfTheGnats
-- Just think: Four billion people in the
world have never received Spam... --

krasicki

unread,
Sep 15, 2002, 9:58:04 AM9/15/02
to
John McClenny <spa...@bebu.com> wrote in message news:<MPG.17edaa83d...@news.supernews.com>...

> In article <3D834C84...@sandbridgetech.com>,
> 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?

Well, John, you already know the answer to that. Thinking cannot be
improved by osmosis or the education system would merely have to group
a smart kid with a dumb kid and pretty soon all the dumb kids would
get smarter. The Agile claims are worse than ludicrous - they are
inane.

Now, the second argument is maybe that the best programmers bring all
the code up to their level in which case the paired shadow is
superfluous and maybe more nuisance than window-dressing.

Finally, some people feel good about it. Hoo-hoo!


> In what way does working solo improve your skills faster than working
> paired?

a.) You can think in peace and quiet.

b.) You can experiment without feeling self-conscious

c.) If you are not a gifted teacher already there's no pressure to
become one.

...the list can go on.



>
> 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 :).

But let's be clear, you would prefer the genius to the morons or am I
being presumptuous?

> 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.

So you send them to school, right?

> I haven't used XP, but don't understand how a system
> that lets me encourage skill sharing and mentoring can be detrimental.

Skills aren't a sharable commodity. Do great athletes improve the
*skills* of those around them?



> Unless, of course, you just want to maximize your skills relative to your
> peers by setting up a system that discourages their improvement :).

Many of us would say, learn what you can working with others as best
you can. But I can't, you can't, Phlip can't, surgeons can't, make
other people smarter, more ambitious, or eager to learn. Life is
cruel that way.

Spend a day in any school, in Washington, D.C., or reading Agile
proponents on this newsgroup - some people will NEVER get it.

John McClenny

unread,
Sep 15, 2002, 2:27:38 PM9/15/02
to
In article <d673fc5d.0209...@posting.google.com>,
kras...@consultant.com says...

> John McClenny <spa...@bebu.com> wrote in message news:<MPG.17edaa83d...@news.supernews.com>...
> > In article <3D834C84...@sandbridgetech.com>,
> > 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?

First, my bias - I am a pointy headed manager - actually, a manager of
PHs. My goals are to get the project done, on time, on budget, with
minimal defects, meeting the customer's needs. My experience has been
that the best TEAM of programmer's tends to meet that goal, not the best
individual programmer's. I reward both team success and individual
success, with the major reward to how well the team functions.

> Well, John, you already know the answer to that. Thinking cannot be
> improved by osmosis or the education system would merely have to group
> a smart kid with a dumb kid and pretty soon all the dumb kids would
> get smarter. The Agile claims are worse than ludicrous - they are
> inane.
>
> Now, the second argument is maybe that the best programmers bring all
> the code up to their level in which case the paired shadow is
> superfluous and maybe more nuisance than window-dressing.

Less experienced programmers can learn from more experienced, and perhaps
better, programmers. Even great programmers can learn from morons who
have a better way of doing one thing. Even the 'shadow' is going to
learn.

> > In what way does working solo improve your skills faster than working
> > paired?
>
> a.) You can think in peace and quiet.
> b.) You can experiment without feeling self-conscious
> c.) If you are not a gifted teacher already there's no pressure to
> become one.
> ...the list can go on.
> >
> > 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 :).
>
> But let's be clear, you would prefer the genius to the morons or am I
> being presumptuous?

It depends on whether the 'genius' is interested and motivated to do all
of the grubby, boring things that building a real product entails. My
best teams have had a mixture of senior and junior people, as well as a
couple of outstanding programmers. The one team I had of all 'stars'
failed miserably and I split them up - they spent all of their time
arguing about what to do and never doing anything.

I am also careful not to give one programmer all of the 'fun' tasks. You
get some of the cream as well the dross. I really discourage the star
system.

As a non-XPer Director, the attractive parts of XP are:

1. Built-in mentoring.
2. Cross-training and cross-ownership of the code.
3. Less ego involved in ownership of any particular piece of code.
4. Less schedule risk - we know what is working.
5. Tighter feedback loops across the entire development spectrum, from
requirements gathering, to design/code, to test, release, and customer
acceptance. This is a biggy for me - I don't need to waste as much
programmer/manager time in status gathering and get a much more realistic
view of where the project is. If the project is going poorly I can react
faster and try to fix the problems. The customer can either invest more
or kill the project sooner based on how well their needs are being met.
We have a continuum of intermediate deliverables.

> > 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.
>
> So you send them to school, right?

Nope, attach a mentor to work with them, maybe a class or two to fill in
holes in their knowledge base, expose them to a wider range of
programming tasks. Specific pieces of knowledge can be learned from
classes, but the skills of programming are either self-discovered or
learned from another skilled practitioner. I try to speed up that
process.

> > I haven't used XP, but don't understand how a system
> > that lets me encourage skill sharing and mentoring can be detrimental.
>
> Skills aren't a sharable commodity. Do great athletes improve the
> *skills* of those around them?

Yes. I used to race whitewater kayaks. I lack the physical skills of
the world-class athletes, but training with them pulled my skill level up
to a much higher level than if I had trained alone. Some of this was
them sharing their insights and observing them, as well was just hanging
with the big dogs. Setting a higher bar results in greater effort.

> > Unless, of course, you just want to maximize your skills relative to your
> > peers by setting up a system that discourages their improvement :).
>
> Many of us would say, learn what you can working with others as best
> you can. But I can't, you can't, Phlip can't, surgeons can't, make
> other people smarter, more ambitious, or eager to learn. Life is
> cruel that way.

But I can remove many barriers to learning and skill improvement within a
programming team. I can reward people for growth, for working within a
team, for team results, as well as their individual contributions in both
design/code and teamwork. I can also fire deadwood, either people who
cannot contribute enough either design/code or teamwork to create a
succesful project.

A lot of this argument seems to pin on whether you believe that great
programmers build great programs or great teams build great programs. I
think great programmers in great teams make the best programs :).

I suspect that you wouldn't like working for me :).

Doc

Phlip

unread,
Sep 15, 2002, 3:14:45 PM9/15/02
to
John McClenny wrote:

> It depends on whether the 'genius' is interested and motivated to do all
> of the grubby, boring things that building a real product entails. 

The XP practice here is that engineers pick which cards they want to do.

> My
> best teams have had a mixture of senior and junior people, as well as a
> couple of outstanding programmers.  The one team I had of all 'stars'
> failed miserably and I split them up - they spent all of their time
> arguing about what to do and never doing anything.

Too many chiefs not enough braves!

> I am also careful not to give one programmer all of the 'fun' tasks.  You
> get some of the cream as well the dross.  I really discourage the star
> system.

However, you "give" programmers tasks. But how close is this to the
XP-style system? Are you giving most tasks based on what you think

On my team, I'm the GUI guy, and someone else is the Repository guy.

When folks behave as if they are about to "assign" me a GUI task, I rebel.
Insufficient opportunities for mentoring.

> As a non-XPer Director, the attractive parts of XP are:
>
> 1. Built-in mentoring.

On my team, dragging colleagues (who often want to treat GUI-building as
authoring instead of programming) thru the details of how to test-first a
UI.

> 2. Cross-training and cross-ownership of the code.
> 3. Less ego involved in ownership of any particular piece of code.

I can't imagine why anyone would (honestly) consider either of these

> 4. Less schedule risk - we know what is working.
> 5. Tighter feedback loops across the entire development spectrum, from
> requirements gathering, to design/code, to test, release, and customer
> acceptance.  This is a biggy for me - I don't need to waste as much
> programmer/manager time in status gathering and get a much more realistic
> view of where the project is.  If the project is going poorly I can react
> faster and try to fix the problems.  The customer can either invest more
> or kill the project sooner based on how well their needs are being met.
> We have a continuum of intermediate deliverables.

An Agile Methodology is one where:

- you can take feature requests in any order
- you can release any integration

Together, they let your customer steer a project.

Taking your team towards those goals will make them Agile, whether or not
you call what you are doing XP.

> Nope, attach a mentor to work with them, maybe a class or two to fill in
> holes in their knowledge base, expose them to a wider range of
> programming tasks.  Specific pieces of knowledge can be learned from
> classes, but the skills of programming are either self-discovered or
> learned from another skilled practitioner.  I try to speed up that
> process.

I can't recommend you adopt any practice that I like which you don't use; I
can't see your existing situation from here. And you should not just start
using any one, or all, of the XP practices until you have seen them in
action.

But if I could, I'd put "All Engineers In One Room" above "Pair
Programming" or other learning situations. Everyone knows where everyone
else is at all times.

> A lot of this argument seems to pin on whether you believe that great
> programmers build great programs or great teams build great programs.   I
> think great programmers in great teams make the best programs :).
>
> I suspect that you wouldn't like working for me :).

Some needy for clearly defined territorial politics wouldn't like working
for you.

--
Phlip
http://www.greencheese.org/LucidScheming
-- Bad nanoprobe! Bad! --

Phlip

unread,
Sep 15, 2002, 3:28:08 PM9/15/02
to
sorry - domestic distractions

Phlip wrote:

> John McClenny wrote:
>
>> It depends on whether the 'genius' is interested and motivated to do all
>> of the grubby, boring things that building a real product entails.
>
> The XP practice here is that engineers pick which cards they want to do.
>
>>My
>> best teams have had a mixture of senior and junior people, as well as a
>> couple of outstanding programmers.  The one team I had of all 'stars'
>> failed miserably and I split them up - they spent all of their time
>> arguing about what to do and never doing anything.
>
> Too many chiefs not enough braves!
>
>> I am also careful not to give one programmer all of the 'fun' tasks.  You
>> get some of the cream as well the dross.  I really discourage the star
>> system.
>
> However, you "give" programmers tasks. But how close is this to the
> XP-style system? Are you giving most tasks based on what you think

someone would have asked for?

--
Phlip
http://www.greencheese.org/LucidScheming
-- Temporomandibular joint disorder
keeping the neighbors awake again? --

Tom Plunket

unread,
Sep 15, 2002, 6:36:27 PM9/15/02
to
krasicki wrote:

> Skills aren't a sharable commodity. Do great athletes improve
> the *skills* of those around them?

My past life was in professional sports (if you were paying
attention you may have seen me in a magazine or two), and I would
definitely say that practicing your skills with people better
than you improves your skills much faster than practice on your
own in a room by yourself. Practicing with other people, even of
comparable skill levels, is more efficient than practicing alone,
if you're paying attention to what the others are doing. You
probably won't learn a lot from people far less skilled than
yourself, but the investment quickly pays off as they reach a
level similar to yours and then your learning starts to
skyrocket.

When I was new in this field I found that I learned much more
quickly working with the sharp people in my group. Now I'm one
of the sharp ones and teach a wide range of material to the
people who come to work with me.

-tom!

Tom Plunket

unread,
Sep 15, 2002, 6:38:40 PM9/15/02
to
Phlip wrote:

> >> 2. Cross-training and cross-ownership of the code.
> >> 3. Less ego involved in ownership of any particular piece of code.
> >
> > I can't imagine why anyone would (honestly) consider either of these

I assume "detrimental" was to be the next word here? ;)

-tom!

krasicki

unread,
Sep 15, 2002, 7:50:13 PM9/15/02
to
John McClenny <spa...@bebu.com> wrote in message news:<MPG.17ee70e2e...@news.supernews.com>...

> In article <d673fc5d.0209...@posting.google.com>,
> kras...@consultant.com says...
> > John McClenny <spa...@bebu.com> wrote in message news:<MPG.17edaa83d...@news.supernews.com>...
> > > In article <3D834C84...@sandbridgetech.com>,
> > > 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?
>
> First, my bias - I am a pointy headed manager - actually, a manager of
> PHs. My goals are to get the project done, on time, on budget, with
> minimal defects, meeting the customer's needs. My experience has been
> that the best TEAM of programmer's tends to meet that goal, not the best
> individual programmer's. I reward both team success and individual
> success, with the major reward to how well the team functions.

No squabble here.


>
> > Well, John, you already know the answer to that. Thinking cannot be
> > improved by osmosis or the education system would merely have to group
> > a smart kid with a dumb kid and pretty soon all the dumb kids would
> > get smarter. The Agile claims are worse than ludicrous - they are
> > inane.
> >
> > Now, the second argument is maybe that the best programmers bring all
> > the code up to their level in which case the paired shadow is
> > superfluous and maybe more nuisance than window-dressing.
>
> Less experienced programmers can learn from more experienced, and perhaps
> better, programmers. Even great programmers can learn from morons who
> have a better way of doing one thing. Even the 'shadow' is going to
> learn.

The argument is not whether or not people can learn. Yes everyone can
learn something - YOU WIN. The problem is whether or not this is the
cost-effective approach to learning, an effective way to do project
development and so on.

But if you are serious about educational theory then knock off the
cutesy "everyone can learn" nonsense and examine exactly what's being
produced or learned.

>
> > > In what way does working solo improve your skills faster than working
> > > paired?
> >
> > a.) You can think in peace and quiet.
> > b.) You can experiment without feeling self-conscious
> > c.) If you are not a gifted teacher already there's no pressure to
> > become one.
> > ...the list can go on.
> > >
> > > 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 :).
> >
> > But let's be clear, you would prefer the genius to the morons or am I
> > being presumptuous?
>
> It depends on whether the 'genius' is interested and motivated to do all
> of the grubby, boring things that building a real product entails.

Yeahhhhhhhhhhhhhhh...

<snip -dialogue on 'star' system>

>
> As a non-XPer Director, the attractive parts of XP are:
>
> 1. Built-in mentoring.

How so? In your existing environment are people allowed to talk,
learn, think?

> 2. Cross-training and cross-ownership of the code.

This is new? different? where is this not the case?

> 3. Less ego involved in ownership of any particular piece of code.

Talk to Phlip - he might "bitch-slap" you for that.

> 4. Less schedule risk - we know what is working.

What does that have to do with schedule? XP does not plan very far in
advance nor does it assume a large scope.

> 5. Tighter feedback loops across the entire development spectrum, from
> requirements gathering, to design/code, to test, release, and customer
> acceptance.

You ARE talking about XP!!!! NOT


> This is a biggy for me - I don't need to waste as much
> programmer/manager time in status gathering and get a much more realistic
> view of where the project is. If the project is going poorly I can react
> faster and try to fix the problems.

Who do you think you are in an XP environment, a pointy headed manager
or just another programmer?

> The customer can either invest more
> or kill the project sooner based on how well their needs are being met.
> We have a continuum of intermediate deliverables.

Aren't YOU special. Sorry, John but lots of people navigate this stuff
just fine without the Agile headache.

> > > 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.
> >
> > So you send them to school, right?
>
> Nope, attach a mentor to work with them, maybe a class or two to fill in
> holes in their knowledge base, expose them to a wider range of
> programming tasks. Specific pieces of knowledge can be learned from
> classes, but the skills of programming are either self-discovered or
> learned from another skilled practitioner. I try to speed up that
> process.

This makes sense to me. As Mr. Natural says, "Twas always thus."


> > > I haven't used XP, but don't understand how a system
> > > that lets me encourage skill sharing and mentoring can be detrimental.
> >
> > Skills aren't a sharable commodity. Do great athletes improve the
> > *skills* of those around them?
>
> Yes. I used to race whitewater kayaks. I lack the physical skills of
> the world-class athletes, but training with them pulled my skill level up
> to a much higher level than if I had trained alone.

But we're not talking about training together. We're talking about
just working together. Why would standing over another's shoulder be
so much better than asking pertinent questions, studying the code of
that same fellow, or just hanfging out in code reviews? It's the same
people with oor without XP.


> Some of this was
> them sharing their insights and observing them, as well was just hanging
> with the big dogs. Setting a higher bar results in greater effort.

Sometimes not. XP is not setting any bars higher - uh-uh.


> > > Unless, of course, you just want to maximize your skills relative to your
> > > peers by setting up a system that discourages their improvement :).
> >
> > Many of us would say, learn what you can working with others as best
> > you can. But I can't, you can't, Phlip can't, surgeons can't, make
> > other people smarter, more ambitious, or eager to learn. Life is
> > cruel that way.
>
> But I can remove many barriers to learning and skill improvement within a
> programming team.

This sounds like an important discovery - how so?

> I can reward people for growth,

What if someone can't grow? What is XP doing for them or you. Why do
you think XP helps people grow any more than going to work anywhere
else? I mean this is truly a phenomenon.

> for working within a
> team, for team results, as well as their individual contributions in both
> design/code and teamwork.

So instead of applying electric shocks to the mice you give them a bit
more cheese. Do people who kiss your ass get more cheese?

> I can also fire deadwood, either people who
> cannot contribute enough either design/code or teamwork to create a
> succesful project.

Nice guy.

>
> A lot of this argument seems to pin on whether you believe that great
> programmers build great programs or great teams build great programs. I
> think great programmers in great teams make the best programs :).

No this argument has nothing to do with programming per se at all.
It's about lifecycle software development.

>
> I suspect that you wouldn't like working for me :).

You might learn something by working WITH me - whoops - did I say
that?

John McClenny

unread,
Sep 16, 2002, 12:13:12 AM9/16/02
to
In article <d673fc5d.02091...@posting.google.com>,
kras...@consultant.com says...

> > > Well, John, you already know the answer to that. Thinking cannot be
> > > improved by osmosis or the education system would merely have to group
> > > a smart kid with a dumb kid and pretty soon all the dumb kids would
> > > get smarter. The Agile claims are worse than ludicrous - they are
> > > inane.
> > >
> > > Now, the second argument is maybe that the best programmers bring all
> > > the code up to their level in which case the paired shadow is
> > > superfluous and maybe more nuisance than window-dressing.
> >
> > Less experienced programmers can learn from more experienced, and perhaps
> > better, programmers. Even great programmers can learn from morons who
> > have a better way of doing one thing. Even the 'shadow' is going to
> > learn.
>
> The argument is not whether or not people can learn. Yes everyone can
> learn something - YOU WIN. The problem is whether or not this is the
> cost-effective approach to learning, an effective way to do project
> development and so on.

Sorry about the tone - I come across much more argumentative on USENET
versus in person. I use these debates to refine my ideas and to learn
other viewpoints. I don't think that our thoughts are really that far
apart - and I like to argue :)

What are the other methods you are suggesting for learning, project
development and management? ( not being argumentative, you may have
ideas I am not familiar with).

One of our areas of confusion may be the time scale of our viewpoints.
You are looking at these tradeoffs from a project point of view while I
am (largely) looking at it from an ongoing organization point of view.
Assume that pair programming is 20% LESS time effective than your
favorite method of SE. Iff pair programming increases the skill level,
job satisfaction, and knowledge base of the junior members at a faster
pace than standard training methods, allowing them to be more productive
on the NEXT project, as well as more likely to stay in the organization,
the time investment is well worth the additional overhead.

The cost to the organization of selecting, hiring, training, and
retaining a programmer outweighs any additional overhead within a single
project. The advantages in productivity of building a well functioning
team outweighs any short-term time investment.

> But if you are serious about educational theory then knock off the
> cutesy "everyone can learn" nonsense and examine exactly what's being
> produced or learned.

I have already preselected reasonably competent people in the hiring
process. I have already fired (or moved to better fitting positions) the
people who either can't or won't learn.

We are not talking about educating the general population here, just
increasing the skills and knowledge levels of a preselected population.
Not everyone in this group will end up at the same skill level - there
will always be brilliant people as well as average performers. But
software development is a team sport requiring a well functioning team to
succeed.

Agile methods speed up feedback loops all along the development process.
As a manager, they provide me quicker feedback on the performance of each
member of the team as well as the overall team. This lets me detect and
fix performance and interpersonal problems before they have a huge impact
on either the project or the team. Long feedback loops are the reason
projects get canceled during year 3 with nothing delivered :(. Short
feedback loops are goodness in software development.

Uncle Bob (Robert C. Martin)

unread,
Sep 16, 2002, 12:25:12 AM9/16/02
to
It is remotely possible that on (or about) 15 Sep 2002 06:58:04
-0700, kras...@consultant.com (krasicki) might (or might not) have
written:

>Thinking cannot be


>improved by osmosis or the education system would merely have to group
>a smart kid with a dumb kid and pretty soon all the dumb kids would
>get smarter. The Agile claims are worse than ludicrous - they are
>inane.

Are you really saying that one person cannot help another to think; to
learn; to grow? If you believe that, then why are you posting here?