Some conclusions regarding XP
ma...@sandbridgetech.com
After looking around at XP, I have come to some conclusions:
XP (probably) works very well when developing
1. programs under 60klocs/year
2. teams containing skewed towards novices/juniors
3. business applications (data-processing, UI et.al.)
4. reasonably mutating specs.
5. moderate correctness requirements
6. (only weakly connected) OO oriented development
XP has several nice practices that initially help programmer development
1. the emphasis on testing
2. pairing (for teaching purposes)
XP will end up inhibiting programmer development, possibly within 1 to 2
years for motivated programmers.
1. The kinds of environments XP is (in my opinion) suited for, and (my
guess) deployed will not stress programmers.
2. The smaller program sizes XP is dealing with also do not impose the
kinds of stresses that help programmers grow.
2. Pair programming prevents programmers from making the kinds of
mistakes that will force them to learn the hard way [note: this is very
good for productivity, but not so good for programmer development]
[An exercise to the reader: ask yourself
- Do I want to write things like the Linux kernel? Apache web server?
gcc compiler? Warcraft III? Quake?
- Can I currently write programs of this kind?
- Will XP give me the programming ability to do so?
]
:)
Mayan
Phlip
> After looking around at XP, I have come to some conclusions:
>
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
Citation?
My team (of 5) is around 200 KLOCs >refactored< per year.
But we cannot stress enough what a terrible metric KLOC is. Make an effort
to ignore it. The map between KLOC refactored and KLOC added is entirely
domain-specific.
The upper bounds of team size, or project size, are unexplored. XP's
existing projects average a size around the same as the industry average
due to penetration, not any scaling problems.
> 2. teams containing skewed towards novices/juniors
Citation?
My team contains mostly seasoned seniors. We are hankering for a better
mix; at which time those novices will get proficient very, very quickly. We
have seen this happen before.
Our most senior coders happen to also be the ones who have been pairing
since before it had a name, and they know much better than to abandon the
process.
A team with a few seniors and many juniors would be ideal for most spaces,
because the communication and feedback spreads the effects of the seniors
around so well.
A team full of only juniors is a recipe for disaster. If you can find a way
around that you'd be a trillionaire.
> 3. business applications (data-processing, UI et.al.)
Citation?
My team is doing raw computer-science research. Our shelves contain old
books full of "documentation" by the BDUF teams who went before us trying
and failing to start what we are now finishing.
> 4. reasonably mutating specs.
Citation?
Our specs have been carved in stone for about 20 years.
Design is the process of resolving conflicting requirements. The order you
do them, or whether future requirements rescind past ones, is irrelevant.
The two ways to design are heroically, or incrementally. XP forces a high
level of incrementalism. The Easy way.
The fact that this incrementalism also lets the OnsiteCustomer steer
towards a business goal is just a happy by-product. Teams typically
progress unaware of steering. The common feeling on the C3 team was "if
someone slipped an air-traffic control user story in amid these paycheck
business rules, we'd just type it in and keep going."
> 5. moderate correctness requirements
Citation?
This is the most erroneous of your assertions. There is nothing anti-XP
about crypto, security, aerospace, high-energy, or medical software. XP
does not mean you sack your QA team to save a buck. In these spaces, the
majority of the user stories will be requests to force a formal
verification, such as path coverage analysis, out of the code base.
> 6. (only weakly connected) OO oriented development
Citation?
Here's UB on comp.object: "I think Test Driven Development is one way to
tell whether you need OO. Very often the solutions I come up with are not
OO (at least not in the small). When an OO solution does come up, it is
often the tests that have driven me to put the abstractions in place."
> XP has several nice practices that initially help programmer development
> 1. the emphasis on testing
> 2. pairing (for teaching purposes)
People always learn. But pairing is primarily about extremely rapid
progress:
http://c2.com/cgi/wiki?BasketballMetaphor
> XP will end up inhibiting programmer development, possibly within 1 to 2
> years for motivated programmers.
Absolute bunk.^H^H Citation?
Why do you think this???
> 1. The kinds of environments XP is (in my opinion) suited for, and (my
> guess) deployed will not stress programmers.
Citation?
Pair programming is exhausting.
Please consider performing the experiment before reporting the results, huh?
> 2. The smaller program sizes XP is dealing with also do not impose the
> kinds of stresses that help programmers grow.
Per Carl Sagan's Baloney Detection Kit, "If there is a chain of argument,
every link in the chain must work."
You can't go from guessing that XP is for trivial apps (your first 1. line
item) to then guessing that trivial apps will bore programmers.
No matter what your methodology, trivial domain spaces will lead to
off-the-shelf solutions. Installing is hardly developing.
> 2. Pair programming prevents programmers from making the kinds of
> mistakes that will force them to learn the hard way [note: this is very
> good for productivity, but not so good for programmer development]
Uh, okay, lack of "School of Hard Knocks". I suppose one might miss out on
learning the ability to solo, or extensive debugger piloting, or UML
without code.
> [An exercise to the reader: ask yourself
> - Do I want to write things like the Linux kernel? Apache web server?
> gcc compiler? Warcraft III? Quake?
> - Can I currently write programs of this kind?
> - Will XP give me the programming ability to do so?
> ]
What the hell^H^H on earth do you think those programs have in common?
Largeness? Extensive feature sets? Deep market penetration?
One thing they do have in common is relentlessly incremental development.
"Apache", the web server, is named as a play on "A Patchy Server" -
referring to the huge number of patches it absorbed during its inflationary
phase.
I'm certain the first few functions written for many of them look little or
nothing like the functions that generate the equivalent abilities in the
current versions.
--
Phlip
http://www.greencheese.org/LucidScheming
-- Who needs a degree when we have Web e-search engines? --
ma...@sandbridgetech.com
Yes, unlike my other posts, I offer no arguments. This is just a summary
of my conclusions, and you are free to disagree with them.
However, I would like you to consider the last question I asked.
> > [An exercise to the reader: ask yourself
> > - Do I want to write things like the Linux kernel? Apache web server?
> > gcc compiler? Warcraft III? Quake?
> > - Can I currently write programs of this kind?
> > - Will XP give me the programming ability to do so?
> > ]
>
> What the hell^H^H on earth do you think those programs have in common?
> Largeness? Extensive feature sets? Deep market penetration?
They are brutally hard to get right, they have fairly tight performance
requirements, they have algorithms that are both large and complex to
code up. Modularization is more difficult. Testing and verification is
quite a different game in these environments.
You have to be an all-round, productive, skilled programmer to work on
them.
Are you already good enough to play in this arena?
If not, when will you get there?
NOTE: I am not saying that a good programmer/team cannot use XP (or any
methodology under the sun) to develop these kinds of programs. I am just
saying that it is my opinion that _IF_ you work exclusively in an XP
environment, _THEN_ you will become
1. average-good more quickly
2. excellent much more slowly
than working in other environments.
As a matter of fact, working in XP for 1-2 years to learn some
fundamental disciplines and development skills, possibly after a
Comp.Sci. degree, is a *GREAT* way to start. However, after that try
working in an environment where you have to tackle these larger
projects. Or try large solo programs. Or work in the embedded arena on
real-time projects.
Acquire a well-rounded bag of tricks/skill set. Become an all-round
programmer.
Mayan
-----------
A major aside, and one I bring up because it is something to think
about:
Someone at IBM who knew Terry Baker, said this about the success of
Chief Programmer Teams and the New York Times project <parapharsed
slightly>:
"Terry Baker was so good that he would make any methodology look great".
Thats a pretty high standard.
Phlip
> However, I would like you to consider the last question I asked.
I did.
>> > [An exercise to the reader: ask yourself
>> > - Do I want to write things like the Linux kernel? Apache web server?
>> > gcc compiler? Warcraft III? Quake?
>> > - Can I currently write programs of this kind?
>> > - Will XP give me the programming ability to do so?
>> > ]
>>
>> What the hell^H^H on earth do you think those programs have in common?
>> Largeness? Extensive feature sets? Deep market penetration?
>
> They are brutally hard to get right, they have fairly tight performance
> requirements, they have algorithms that are both large and complex to
> code up. Modularization is more difficult. Testing and verification is
> quite a different game in these environments.
Right. And there's nothing about them that's anti-XP.
Per the "every link in the chain must work", you have assumed this entire
list of "problems" with XP, entirely without citations, and then picked
some killer apps that you then propose will show XP failing. Link link link.
> You have to be an all-round, productive, skilled programmer to work on
> them.
Wrong. Someone very good at patching Linux's kernel could be appalling at
user interfaces. (Historically, this explains much of Unix's middle strata.)
TDD provides the ability to Refactor Mercilessly. The latter is an
exceptionally good way to leverage an entire team's ability to partition
things into modules. Any decoupling technique you can think of (Dependency
Inversion Principle, Interface Segregation Principle, Open Closed
Principle, Hierarchical Encapsulation, the Design Patterns, etc.) if you
overlooked it for some part of the code, or if that code changed and the
potential for it emerged, you just fearlessly put it in.
The result is many modules that look very small, containing classes that
look small, containing short methods.
A lot of the projects you listed would have much healthier interiors if
they'd been written in a way that enabled Refactor Mercilessly. Free
Software is a beautiful concept, but it encourages small patches that solve
bugs and add features, not large patches that improve design. A patch that
refactored some cruft out would be huge and would hit many dispersed areas,
so it would be very hard for a lieutenant to approve.
Linux's kernel is very healthy, but I suspect in general one could not say
the above projects have modules that look small.
> Are you already good enough to play in this arena?
> If not, when will you get there?
Is that "you" in the plural? I, in the singular, >am< there.
> NOTE: I am not saying that a good programmer/team cannot use XP (or any
> methodology under the sun) to develop these kinds of programs. I am just
> saying that it is my opinion that _IF_ you work exclusively in an XP
> environment, _THEN_ you will become
> 1. average-good more quickly
> 2. excellent much more slowly
> than working in other environments.
Absolutely wrong. XP teams, by the very nature of adopting a rising
technology early, tend to be those in pursuit of excellence, who thrive on
chaos.
> As a matter of fact, working in XP for 1-2 years to learn some
> fundamental disciplines and development skills, possibly after a
> Comp.Sci. degree, is a *GREAT* way to start. However, after that try
> working in an environment where you have to tackle these larger
> projects. Or try large solo programs. Or work in the embedded arena on
> real-time projects.
The engineers I know experiment instead of making up elaborate results.
> A major aside, and one I bring up because it is something to think
> about:
> Someone at IBM who knew Terry Baker, said this about the success of
> Chief Programmer Teams and the New York Times project <parapharsed
> slightly>:
> "Terry Baker was so good that he would make any methodology look great".
> Thats a pretty high standard.
Chief Programmer Team is the worst, and hardly the place to develop
well-rounded skill sets. Even if you'r the chief.
--
Phlip
http://www.greencheese.org/MakeItSo
-- But all the other programmers were doing it! --
Uncle Bob (Robert C. Martin)
>Yes, unlike my other posts, I offer no arguments. This is just a summary
>of my conclusions, and you are free to disagree with them.
This issue I take with your "conclusions" is that they don't appear to
be based upon experiment or observation. They make a fine hypothesis,
but without experiment and observation they aren't any kind of
conclusion at all.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |
You and I can enjoy the experience of not always seeing
eye-to-eye, but we can also respect each other, even when
you might find some idea of mine totally ludicrous.
-- Richard Riehle
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> On Sun, 08 Sep 2002 11:06:58 -0400, ma...@sandbridgetech.com wrote:
>
> >Yes, unlike my other posts, I offer no arguments. This is just a summary
> >of my conclusions, and you are free to disagree with them.
>
> This issue I take with your "conclusions" is that they don't appear to
> be based upon experiment or observation. They make a fine hypothesis,
> but without experiment and observation they aren't any kind of
> conclusion at all.
Ah, okay - call it my opinion instead :)
Like I said feel free to disagree with me; I'm not trying (really hard)
to convince anyone of anything about XP.
In retrospect, the only thing I feel somewhat strongly about - that XP,
like any methodology, eventually morphs from a support to a crutch - is
not going to make a big difference to its intended audience. Programmers
who are good but want to be better will realize sooner or later that its
time to try something different. And they will take a solid grounding in
decent practices with them. Hopefully, once they learn why certain rules
were created, and when they should be broken, they will still use some
of XP's practices. But, it is unlikely that the process they adopt will
always be XP - or even something resembling XP.
Mayan
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > However, I would like you to consider the last question I asked.
Perhaps I should rephrase the questions:
- are you as good a programmer as you can be?
- will XP get you all the way there?
What is your answer?
Mayan
Phlip
> Perhaps I should rephrase the questions:
> - are you as good a programmer as you can be?
> - will XP get you all the way there?
Okay. No, and no.
But having seen XP morph from a support into wings, I have no doubt that
the most advanced things I will do in my career will involve The Twelve
Practices.
I'm quite curious see what new things it will also involve.
--
Phlip
http://c2.com/cgi/wiki?SheChangeDesignInTheDatabase
-- Founding member of NuGWa -
Nudists for Global Warming --
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > However, I would like you to consider the last question I asked.
>
> I did.
>
> >> > [An exercise to the reader: ask yourself
> >> > - Do I want to write things like the Linux kernel? Apache web server?
> >> > gcc compiler? Warcraft III? Quake?
> >> > - Can I currently write programs of this kind?
> >> > - Will XP give me the programming ability to do so?
> >> > ]
> >>
> >> What the hell^H^H on earth do you think those programs have in common?
> >> Largeness? Extensive feature sets? Deep market penetration?
> >
> > They are brutally hard to get right, they have fairly tight performance
> > requirements, they have algorithms that are both large and complex to
> > code up. Modularization is more difficult. Testing and verification is
> > quite a different game in these environments.
> Right. And there's nothing about them that's anti-XP.
Agreed. Absolutely. This isn't about XP or not-XP. This is about the
programmers that work on them. They have a certain expertise level. If
they choose to use XP, or some subset of XP, or some other process which
involves XP, it is because they have the knowledge of a lot of practices
_other_than_XP_, and the wisdom to pick the ones that fit the task.
The originators of XP, and the senior programmers who use XP will also
have followed the same path - they probably know a lot of other
practices than those embodied within XP, and then they winnowed them
down to fit a general populace of programmers and the most common
programs they write.
A novice does not know all the alternatives available. He/she does not
know why and when not to use a certain rule.
>
> Per the "every link in the chain must work", you have assumed this entire
> list of "problems" with XP, entirely without citations, and then picked
> some killer apps that you then propose will show XP failing. Link link link.
>
> > You have to be an all-round, productive, skilled programmer to work on
> > them.
>
> Wrong. Someone very good at patching Linux's kernel could be appalling at
> user interfaces. (Historically, this explains much of Unix's middle strata.)
Absolutely possible. However, wouldn't a programmer who is capable of
doing both a better programmer?
> TDD provides the ability to Refactor Mercilessly. The latter is an
> exceptionally good way to leverage an entire team's ability to partition
> things into modules. Any decoupling technique you can think of (Dependency
> Inversion Principle, Interface Segregation Principle, Open Closed
> Principle, Hierarchical Encapsulation, the Design Patterns, etc.) if you
> overlooked it for some part of the code, or if that code changed and the
> potential for it emerged, you just fearlessly put it in.
>
> The result is many modules that look very small, containing classes that
> look small, containing short methods.
:) Anyone who thinks its possible to write an OS kernel that way, has
never really looked at the problem. This is an easy way of getting
disastrous performance. I would suggest looking at OSF and what they had
to do get it to perform even reasonably.
What are the performance implications of OO? What is the difference in
run-time performance between a function call, a statically bound virtual
function call (C++ virtual functions) and a dynamically bound virtual
function call (Smalltalk, I think)? Do you know why there is a
difference?
99% of the time, and 99% of programmers don't need to know the answer to
these questions. However, the extent to which you are aware of all these
details will determine how complete and versatile a programmer you are.
> A lot of the projects you listed would have much healthier interiors if
> they'd been written in a way that enabled Refactor Mercilessly. Free
> Software is a beautiful concept, but it encourages small patches that solve
> bugs and add features, not large patches that improve design. A patch that
> refactored some cruft out would be huge and would hit many dispersed areas,
> so it would be very hard for a lieutenant to approve.
Note that gcc has undergone 2 complete rewrites [at least]. Things did
get cleaned up. The most recent rewrite was a couple years ago. A
question - do you know why they implemented it the way they did? Is it
different than the way you would have done it? Why might they have
picked a different approach than yours?
> Linux's kernel is very healthy, but I suspect in general one could not say
> the above projects have modules that look small.
>
> > Are you already good enough to play in this arena?
> > If not, when will you get there?
>
> Is that "you" in the plural? I, in the singular, >am< there.
:) What are you working on?
BTW: this is a somewhat personal note [and it _does_ look like a
personal attack but please believe that I am not using ad hominem],
based on your previous notes, you aren't; among other things you seem to
be light in your knowledge of algorithms, and in your systems
programming experience. Of course, I could very easily be wrong - a
stream of Usenet articles is not a good foundantion on which to make a
judgement.
> > NOTE: I am not saying that a good programmer/team cannot use XP (or any
> > methodology under the sun) to develop these kinds of programs. I am just
> > saying that it is my opinion that _IF_ you work exclusively in an XP
> > environment, _THEN_ you will become
> > 1. average-good more quickly
> > 2. excellent much more slowly
> > than working in other environments.
>
> Absolutely wrong. XP teams, by the very nature of adopting a rising
> technology early, tend to be those in pursuit of excellence, who thrive on
> chaos.
<grin> I kind of like that.
> > As a matter of fact, working in XP for 1-2 years to learn some
> > fundamental disciplines and development skills, possibly after a
> > Comp.Sci. degree, is a *GREAT* way to start. However, after that try
> > working in an environment where you have to tackle these larger
> > projects. Or try large solo programs. Or work in the embedded arena on
> > real-time projects.
>
> The engineers I know experiment instead of making up elaborate results.
>
> > A major aside, and one I bring up because it is something to think
> > about:
> > Someone at IBM who knew Terry Baker, said this about the success of
> > Chief Programmer Teams and the New York Times project <parapharsed
> > slightly>:
> > "Terry Baker was so good that he would make any methodology look great".
> > Thats a pretty high standard.
>
> Chief Programmer Team is the worst, and hardly the place to develop
> well-rounded skill sets. Even if you'r the chief.
I absolutely agree. I don't like the CPT idea. However, the question
was: are you good enough to take a methodology - any methodology - and
make it look good?
Mayan
----
I'm into stories these days :) As long as no one really reads too much
into it, here is a Zen parable <as best as I can remember it>:
A student comes to the master, and asks to be led to enlightenment. So,
the master takes him outdoors and sits him down.
"What do you see?" he asks
"I see a mountain with some trees and a stream" replies the student
The master leaves. Several years later he comes back, and asks the
student to tell him what he sees. The student goes into a long
narrative, describing the individual rocks on the mountain, the leaves
on the trees, the course of the stream, the way it sounds, etc.
The master leaves. After several years, he comes back, and asks the
student:
"What do you see?"
"I see a mountain with some trees and a stream"
Phlip
ma...@sandbridgetech.com wrote:
> The originators of XP, and the senior programmers who use XP will also
> have followed the same path - they probably know a lot of other
> practices than those embodied within XP, and then they winnowed them
> down to fit a general populace of programmers and the most common
> programs they write.
The early leaders of the OO movement had a long struggle to codify what
they were doing. Just adding OO abilities to languages and publishing these
was not enough, because newbies still use these languages poorly, causing
problems instead of solving them.
Design Patterns, and then XP, represent the next wave of codification. In
the olden days, these natural geniuses did not say "pairing" or
"test-first"; they just did them, and they did not know how to describe
their lifecycles to newbies in ways that were safe to transcribe.
When the OO movement acquired a second tier, full of programmer/authors,
then the codification began.
>> Wrong. Someone very good at patching Linux's kernel could be appalling at
>> user interfaces. (Historically, this explains much of Unix's middle
>> strata.)
>
> Absolutely possible. However, wouldn't a programmer who is capable of
> doing both a better programmer?
Thank you. <blushing>
>> The result is many modules that look very small, containing classes that
>> look small, containing short methods.
>
> :) Anyone who thinks its possible to write an OS kernel that way, has
> never really looked at the problem. This is an easy way of getting
> disastrous performance. I would suggest looking at OSF and what they had
> to do get it to perform even reasonably.
I held up Linux as the good example among the bad here.
> What are the performance implications of OO?
Ouch. Another thread. Make it right, then make it fast. OO >means< "easily
changed code", so tuning is just changing.
> 99% of the time, and 99% of programmers don't need to know the answer to
> these questions. However, the extent to which you are aware of all these
> details will determine how complete and versatile a programmer you are.
Right. XP is orthogonal here.
> A
> question - do you know why [g++] implemented it the way they did? Is it
> different than the way you would have done it? Why might they have
> picked a different approach than yours?
Sorry. I'm contracting here. I'm sure we can find plenty of my bad examples
in Free Software land.
> :) What are you working on?
>
> BTW: this is a somewhat personal note [and it _does_ look like a
> personal attack but please believe that I am not using ad hominem],
> based on your previous notes, you aren't; among other things you seem to
> be light in your knowledge of algorithms, and in your systems
> programming experience. Of course, I could very easily be wrong - a
> stream of Usenet articles is not a good foundantion on which to make a
> judgement.
Oh, thank you. I'm sure you are familiar with the acronym NDA.
I'm helping to invent a new kind of computer. Lots of algorithms, systems
programming, etc.
Being good at algorithms (not saying I am) is not the same thing as being
able to write about them or lecture online about them.
> I absolutely agree. I don't like the CPT idea. However, the question
> was: are you good enough to take a methodology - any methodology - and
> make it look good?
Yes, but only so good.
> "I see a mountain with some trees and a stream"
--
Phlip
http://www.greencheese.org/LucidScheming
-- My opinions are those of your employer --
John Roth
"Phlip" <phli...@yahoo.com> wrote in message
news:KFKe9.381$ct....@newssvr19.news.prodigy.com...
> ma...@sandbridgetech.com wrote:
>
>
> > A major aside, and one I bring up because it is something to think
> > about:
> > Someone at IBM who knew Terry Baker, said this about the success of
> > Chief Programmer Teams and the New York Times project <parapharsed
> > slightly>:
> > "Terry Baker was so good that he would make any methodology look
great".
> > Thats a pretty high standard.
>
> Chief Programmer Team is the worst, and hardly the place to develop
> well-rounded skill sets. Even if you'r the chief.
As I've said before, and I'll probably say again, the scenery is
littered
with the corpses of methodologies that worked for very exceptional
individuals. Most of them fail when the more average people that are the
mainstay of any profession attempt to put them into practice.
CPT is one such methodology. So far XP does not appear to
be in that class.
John Roth
John Roth
<ma...@sandbridgetech.com> wrote in message
news:3D7B95D8...@sandbridgetech.com...
>
>
> Phlip wrote:
> >
> > Chief Programmer Team is the worst, and hardly the place to develop
> > well-rounded skill sets. Even if you'r the chief.
>
> I absolutely agree. I don't like the CPT idea. However, the question
> was: are you good enough to take a methodology - any methodology - and
> make it look good?
Not being a masochist, and not having anything to prove, I have no
intention of
trying to make a terminally stupid idea look good.
John Roth
>
> Mayan
>
> ----
>
> I'm into stories these days :) As long as no one really reads too much
> into it, here is a Zen parable <as best as I can remember it>:
> A student comes to the master, and asks to be led to enlightenment.
So,
> the master takes him outdoors and sits him down.
> "What do you see?" he asks
> "I see a mountain with some trees and a stream" replies the student
> The master leaves. Several years later he comes back, and asks the
> student to tell him what he sees. The student goes into a long
> narrative, describing the individual rocks on the mountain, the leaves
> on the trees, the course of the stream, the way it sounds, etc.
> The master leaves. After several years, he comes back, and asks the
> student:
> "What do you see?"
> "I see a mountain with some trees and a stream"
That's not quite the way I remember the story, but then, I suppose
there are multiple variants out there. It's a story about the interior
of the
learning process. Presumably, after it is all over, the student can
describe
the details much better than he could at the beginning, but feels no
particular need to dwell on them.
JR.
Uncle Bob (Robert C. Martin)
I completely agree with this -- though it is a far cry from your
previous statement.
>- or even something resembling XP.
I don't know about this last one. Maybe, maybe not. Time will tell.
krasicki
characters on Saturday Night Live. When confronted by a hero, they
wave their hands in respect and say, "I am not worthy."
You have done a wonderful service in the dialogues you've participated
in. Although in a subsequent thread you defer to calling the
following 'opinions', I am inclined to think that they are very close
to being rules-of-thumb for determining the Agile methodology value to
programmers and to companies investigating the genre.
I add my own observations, opinions, and comments because I have been
wrestling with many of these same issues for many months and this
seems a great point of closure for some of the issues.
ma...@sandbridgetech.com wrote in message news:<3D7AD16E...@sandbridgetech.com>...
> After looking around at XP, I have come to some conclusions:
>
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
I would add also projects of that scale that favor and accomodate
rapid application development techniques.
> 2. teams containing skewed towards novices/juniors
Or cheap labor.
XP is a very image conscious phenomenon. Much of the early rhetoric
has faded and using newsgroups as feedback loops it has tightened its
vocabulary and appeal to individuals predispositioned to cults,
exclusivity litmus testing, and so on. It fancies itself *new* and
fashionable, a bias that appeals to youth.
It also is predisposed to very loosey-goosey environments where
egalitarian sentiments can be coupled with modular, one-room, open,
no-privacy working spaces.
It is also predisposed to environments willing to short-circuit
existing checks and balances between abstraction specialists
[architects, designers, BAs], coders, and QA.
It also appeals to environments who want to streamline personnel costs
at any cost. It may accelerate the stream of programming jobs
elsewhere no matter who you are. Because the cost-benefit of pair
programming has not been definitively proven, common sense dictates
that hiring two programmers for the price of one elsewhere solves the
equation.
Under pair programming guidelines, licensed software purchases may be
cut by 50% in participating environments weakening even the software
factory's economics.
> 3. business applications (data-processing, UI et.al.)
I might interject that the bias might be toward new projects and in
environments where the programming staff is given a litmus test -
conform or exit. Senior staff would likely be shown the door or pair
program.
> 4. reasonably mutating specs.
Agreed. And less likely in maintenance environments.
> 5. moderate correctness requirements
The bias being toward architectures that are in place, frameworks
decided, generally homogenous systems, few rough edges or surprises.
> 6. (only weakly connected) OO oriented development
Agreed.
>
> XP has several nice practices that initially help programmer development
> 1. the emphasis on testing
I disagree somewhat here. Appropriate testing should be an emphasis
in all development methodologies. It is commendable that XP recommends
it. It is questionable whether TDD is a healthy way to proceed.
> 2. pairing (for teaching purposes)
Again, every methodology should emphasize collaboration as needed. Xp
is no more exceptional in this regard than programmers who are smart
enough to ask questions of appropriate personnel. One might argue
that important social navigation skills are sacrificed by the
regimented pairings.
>
> XP will end up inhibiting programmer development, possibly within 1 to 2
> years for motivated programmers.
Coupled with TDD, it could be detrimental to understanding the
precepts of programming itself.
> 1. The kinds of environments XP is (in my opinion) suited for, and (my
> guess) deployed will not stress programmers.
> 2. The smaller program sizes XP is dealing with also do not impose the
> kinds of stresses that help programmers grow.
An important and understated point.
> 2. Pair programming prevents programmers from making the kinds of
> mistakes that will force them to learn the hard way [note: this is very
> good for productivity, but not so good for programmer development]
It might promote logic mistakes that will be impossible for the
program authors to comprehend if they know nothing but XP. The
constrained coding world may very well turn into a very real
intellectual flatland.
>
> [An exercise to the reader: ask yourself
> - Do I want to write things like the Linux kernel? Apache web server?
> gcc compiler? Warcraft III? Quake?
> - Can I currently write programs of this kind?
> - Will XP give me the programming ability to do so?
> ]
>
> :)
> Mayan
krasicki: Thanks for the thought experiments.
Kevin Cline
>
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
> 2. teams containing skewed towards novices/junior
I'm wondering what led you to this conclusion.
On the contrary, and like most everything other endeavor,
I think XP works better when the team is highly skilled.
I have done pair programming with other strong developers and found
it incredibly productive and enjoyable. I believe there are
very top-flight programmers who would not enjoy pairing.
The people who resisted pairing seemed to be those whose code
was most in need of refactoring.
Phlip
> You have done a wonderful service in the dialogues you've participated
> in. Although in a subsequent thread you defer to calling the
> following 'opinions', I am inclined to think that they are very close
> to being rules-of-thumb for determining the Agile methodology value to
> programmers and to companies investigating the genre.
Translation: Making things up off the top of your head that agree with
things I made up means more to me than reports of real experience.
--
Phlip
http://www.greencheese.org/LucidScheming
-- Have a :-) day --
David B Lightstone
If you have a citation, it is publically available for review.
Common sense would suggest that citations be provided by the author of the
study, not his alias
"Phlip" <phli...@yahoo.com> wrote in message
news:S2Be9.515$fq5.21...@newssvr15.news.prodigy.com...
David B Lightstone
> krasicki wrote:
>
> > You have done a wonderful service in the dialogues you've participated
> > in. Although in a subsequent thread you defer to calling the
> > following 'opinions', I am inclined to think that they are very close
> > to being rules-of-thumb for determining the Agile methodology value to
> > programmers and to companies investigating the genre.
>
> Translation: Making things up off the top of your head that agree with
> things I made up means more to me than reports of real experience.
If you have learned anything in life Phlip, surely it must have been the
reports are sometimes fabricated.
Here I am not calling you a fabricator, rather I am just observing a long
standing tradition in Science. Claims unsubstanciated with publically
examinable evidence are assumed to be fabrications. Such is the ethos of
Science. The proverbial can you duplicate the results mean just that
identical (within measurable experimental error) conditions and results. It
does not mean similar or any
The experience argument which you present is just a political mechanism
used to disenfranchise those with whom you disagree. By definition
experience which contradicts is usually greated with the remarks:
(1) You are doing something wrong (as opposed to you are doing something
differently)
(2) You are fabricating
(3) You are a troll
nobody does anything according the the ideal of the methodology. Obviously
there are tradeoffs and one must realize their consequences. This by means
of characterization and by means of determining the basis for the selected
tradeoffs.
Finally because problem solving is not a systematic craft (ie TDD can be
interpreted, by me, probably not by you, as an attempt to establish an
systematic problem solving craft) you have to fake it via a post solution
discover activity of reformulation to fit the ideal. At best your TDD is an
element of that reformulation
Tom Plunket
> > [An exercise to the reader: ask yourself
> > - Do I want to write things like the Linux kernel? Apache web server?
> > gcc compiler? Warcraft III? Quake?
> > - Can I currently write programs of this kind?
> > - Will XP give me the programming ability to do so?
> > ]
According to a guy I roundtabled with at the Game Developers'
Conference last May, Blizzard (creators of Warcraft) is doing
extreme programming on some of their projects.
Additionally, there are other game development studios in various
stages of agile adoption scattered around (if the people in this
roundtable weren't lying).
-tom!
John Roth
"Tom Plunket" <to...@fancy.org> wrote in message
news:ljo1ouoh6h1qmo4je...@4ax.com...
Hi tom! Glad to see you back on the ng.
John Roth
>
> -tom!
Tom Adams
> ma...@sandbridgetech.com wrote:
>
> > After looking around at XP, I have come to some conclusions:
> >
> > XP (probably) works very well when developing
> > 1. programs under 60klocs/year
>
> Citation?
>
Philip,
You ask for citations many times in your post. However, you offer
no citations to support your own claims. The only citation that your
post includes is a link to a cartoon site in your signature.
Please practice what you preach.
David B Lightstone
"Tom Adams" <tada...@yahoo.com> wrote in message
news:ea44f5a1.0209...@posting.google.com...
Give him a break, he can't provide citations without revealing his
identity.
Perhaps on day he will have a "friend" post citations in his behalf. Until
then we have the word of Phlip.
Ron Jeffries
>[An exercise to the reader: ask yourself
>- Do I want to write things like the Linux kernel? Apache web server?
>gcc compiler? Warcraft III? Quake?
>- Can I currently write programs of this kind?
>- Will XP give me the programming ability to do so?
My teams and I have written operating systems, relational database systems,
language compilers,graphical display software, applications software of many
kinds, and even a bit of real-time control.
And I have done XP. I would use XP for every one of those kinds of work were I
to do them again.
Have you tried XP yet, mayan? Or are you speculating?
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Ron Jeffries
I hope I'm not as good as I can be, since I've only worked on those things I
listed in another post on this thread and have only programmed, let's see ...
IBM 704/7090/7094/1401/360...
DEC PDP-1/PDP-7/PDP-8
Burroughs E-101 if you think that's programming
SDS 940
Xerox Sigma 7/Sigma 9
Apple ][
Intel from 8080 on.
I've written a lot of programs. I could write any and all of them test-driven.
I'd rather do so. I'd rather do them all pairing. I could now estimate any of
them, deliver them incrementally so that management/business could know what was
going on.
XP will get me anywhere I might need to go. What do you imagine it might not let
you do that you've already done, or that you might want to do?
And ... tell us about the XP projects you've been on, please.
ma...@sandbridgetech.com
Ron Jeffries wrote:
>
> On Sun, 08 Sep 2002 00:26:22 -0400, ma...@sandbridgetech.com wrote:
>
> >[An exercise to the reader: ask yourself
> >- Do I want to write things like the Linux kernel? Apache web server?
> >gcc compiler? Warcraft III? Quake?
> >- Can I currently write programs of this kind?
> >- Will XP give me the programming ability to do so?
>
> My teams and I have written operating systems, relational database systems,
> language compilers,graphical display software, applications software of many
> kinds, and even a bit of real-time control.
And all this was done using XP? I find that hard to believe - VERY hard
to believe. But I would be happy to be proven wrong :)
Are there any specific projects you can mention? Any details? Write-ups?
I'd be particularily interested in hearing about the O.S. and compiler
work that you/your team did using XP.
[Now if you did this using disciplines/methodologies that were *NOT* XP,
but had *SOME* of the practices of XP (or even none of them), now that I
would find believable]
> And I have done XP. I would use XP for every one of those kinds of work were I
> to do them again.
It would depend on the team and the project, for me.
> Have you tried XP yet, mayan? Or are you speculating?
XP - no. Some XP practices - for a long, _LONG_ time.
ma...@sandbridgetech.com
Ron, I think you're missing the point - my claim was that XP would
inhibit programmer development (after a point, probably 1-2 years for a
good programmer). You *personally* have a lot of programming skills. But
I will bet that you picked 90%+ of them up in environments other than
XP.
Now that you have those skills, you may be able to use them effectively
in the context of XP. *BUT*
a) you have other skills/experiences to fall back on.
b) you use them (probably daily) to influence the things you do.
Ron Jeffries wrote:
>
> On Sun, 08 Sep 2002 13:49:09 -0400, ma...@sandbridgetech.com wrote:
>
> >> > However, I would like you to consider the last question I asked.
> >
> >Perhaps I should rephrase the questions:
> >- are you as good a programmer as you can be?
> >- will XP get you all the way there?
> >
> >What is your answer?
>
> I hope I'm not as good as I can be, since I've only worked on those things I
> listed in another post on this thread and have only programmed, let's see
<snipped impressive list of machines>
>
> I've written a lot of programs.
Most of them non-XP
> I could write any and all of them test-driven.
An operating system kernel? An optimizing compiler? For commercial use?
In that case your defition of either TDD or adequate testing differs
considerably from mine. I'd want a seperate, large set of both white and
black box tests written post-facto.
BTW: what team-sizes are you look at?
> I'd rather do so. I'd rather do them all pairing.
O.K.
> I could now estimate any of
> them, deliver them incrementally so that management/business could know what was going on.
Alright lets test thins: here's one:
Goal: develop an optimizing C compiler back-end, with at least the
optimizations to be found in gcc. What is your estimates for:
- man years
- team size
- loc
- test-suite size
> XP will get me anywhere I might need to go. What do you imagine it might not let
> you do that you've already done, or that you might want to do?
Hmm...
- O.S. kernels
- compilers
- avionics software
- any project that is large/complex/mission-critical
> And ... tell us about the XP projects you've been on, please.
None.
Now let me ask - how many medium-to-large XP projects other than the C3
one have you done? (Not provide mentoring for, or consulted on, but
actually programmed on, more-or-less from beginning to end)
:)
Mayan
Phlip
> Ron, I think you're missing the point - my claim was that XP would
> inhibit programmer development (after a point, probably 1-2 years for a
> good programmer).
XP has been around for >5 years, and folks were doing most of its practices
for a decade or so without a name. We've had enough time to collect
evidence regarding any limit to its growth curve. Such data would have come
in the form of a series of Wiki pages, mailing list messages and newsgroup
messages from many 2-year alumni saying, "I got bored with XP and moved on.
Later, folks."
Myself? 3 years and counting. And if you challenge my programming abilities
(by claiming my development is somehow inhibited) I will write code that
bitch-slaps yours into next week. 8-)
--
Phlip
http://www.greencheese.org/AndNowaNitelyLitelyUrbanOne
-- How does Bugs Bunny do it? How does he know when he
wakes up in the morning to put in his pocket 3 sticks
of dynamite, a physician costume, and a bicycle pump? --
David B Lightstone
<ma...@sandbridgetech.com> wrote in message
news:3D83473E...@sandbridgetech.com...
I think that pretty much articulates the experiences of anybody with more
than say 5 years experience in this game.
Somehow, someone, (that's you Ronn), thinks, the only way an individual can
understand the implications of new ideas (or even bad old one) on their
daily activities, is via experimentation. Sorry to upset your apple cart
Ronn, but as long as the extrapolation is not excessive, it can be done.
Human beings have been doing it for a rather long time.
Now if you want to say that the practices of eXtreme programming, are such
that the extrapolation just is not valid. I certainly will not disagree. I
can't speak for those who disagree for the sake of disagreeing. There is
always someboddy who is disagreeable
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > Ron, I think you're missing the point - my claim was that XP would
> > inhibit programmer development (after a point, probably 1-2 years for a
> > good programmer).
>
> XP has been around for >5 years, and folks were doing most of its practices
> for a decade or so without a name. We've had enough time to collect
> evidence regarding any limit to its growth curve. Such data would have come
> in the form of a series of Wiki pages, mailing list messages and newsgroup
> messages from many 2-year alumni saying, "I got bored with XP and moved on.
> Later, folks."
<grin> I haven't seen evidence of any serious project being mounted
using XP either. So they definitely aren't progressing up the complexity
chain either.
About the only claims that I have seen are:
- 200klocs of code for something which is under NDA
[heck, data mining software? on a Linux cluster connected with ATM
switches? Come on - why can't people talk about that in general terms at
least]
- blizzard software is using it for some of their programming.
[Good; can we get any details? Are they using it for their gaming
engine? For their graphics engine? Or something else?]
- "embedded" software environments - still no idea what specifically -
IDEs/BSPs are embedded software environments, and so are device drivers.
> Myself? 3 years and counting. And if you challenge my programming abilities
> (by claiming my development is somehow inhibited) I will write code that
> bitch-slaps yours into next week. 8-)
<grin> ok, ok, you _DO_ have a bigger dick than mine :)
On the other hand - you have no evidence of what my programming
abilities are. They might be a tad bit better than you suspect :)
Mayan
Phlip
> <grin> I haven't seen evidence of any serious project being mounted
> using XP either. So they definitely aren't progressing up the complexity
> chain either.
Speak for yourself.
--
Phlip
http://c2.com/cgi/wiki?SheChangeDesignInTheDatabase
Uncle Bob (Robert C. Martin)
GMT, "David B Lightstone" <david.lightst...@prodigy.net>
might (or might not) have written:
>There is always someboddy who is disagreeable
Agreed.
Uncle Bob (Robert C. Martin)
GMT, "David B Lightstone" <david.lightst...@prodigy.net>
might (or might not) have written:
>Somehow, someone, (that's you Ronn), thinks, the only way an individual can
>understand the implications of new ideas (or even bad old one) on their
>daily activities, is via experimentation. Sorry to upset your apple cart
>Ronn, but as long as the extrapolation is not excessive, it can be done.
>Human beings have been doing it for a rather long time.
Yes, they have. They extrapolated that since feathers fell slower
than rocks, heavy things fall proportionally faster than light things.
That extrapolation lasted two thousand years.
Extrapolation of this kind is called -- guessing. Sometimes it
works, sometimes it doesn't. If you want to *know* something, you
have to do the experiments.
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
>
>
>Phlip wrote:
>>
>> ma...@sandbridgetech.com wrote:
>>
>> > Ron, I think you're missing the point - my claim was that XP would
>> > inhibit programmer development (after a point, probably 1-2 years for a
>> > good programmer).
>>
>> XP has been around for >5 years, and folks were doing most of its practices
>> for a decade or so without a name. We've had enough time to collect
>> evidence regarding any limit to its growth curve. Such data would have come
>> in the form of a series of Wiki pages, mailing list messages and newsgroup
>> messages from many 2-year alumni saying, "I got bored with XP and moved on.
>> Later, folks."
>
><grin> I haven't seen evidence of any serious project being mounted
>using XP either. So they definitely aren't progressing up the complexity
>chain either.
There are *lots* of very serious projects that are currently using XP.
These projects span many different industries and many different
environments. They range from embedded real-time to scientific to
financial, to MIS. The companies using XP range from tiny consulting
shops, to start ups, to Fortune 500 companies in virtually every
field.
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> It is remotely possible that on (or about) Sat, 14 Sep 2002 11:47:32
> -0400, ma...@sandbridgetech.com might (or might not) have written:
>
> >
> >
> >Phlip wrote:
> >>
> >> ma...@sandbridgetech.com wrote:
> >>
> >> > Ron, I think you're missing the point - my claim was that XP would
> >> > inhibit programmer development (after a point, probably 1-2 years for a
> >> > good programmer).
> >>
> >> XP has been around for >5 years, and folks were doing most of its practices
> >> for a decade or so without a name. We've had enough time to collect
> >> evidence regarding any limit to its growth curve. Such data would have come
> >> in the form of a series of Wiki pages, mailing list messages and newsgroup
> >> messages from many 2-year alumni saying, "I got bored with XP and moved on.
> >> Later, folks."
> >
> ><grin> I haven't seen evidence of any serious project being mounted
> >using XP either. So they definitely aren't progressing up the complexity
> >chain either.
>
> There are *lots* of very serious projects that are currently using XP.
> These projects span many different industries and many different
> environments. They range from embedded real-time to scientific to
> financial, to MIS. The companies using XP range from tiny consulting
> shops, to start ups, to Fortune 500 companies in virtually every
> field.
>
Excellent! Are there any names, references etc. that you are free to
give? It would be nice to get some info from the trenches - or even an
idea of what XP is being used for. So far, I haven't gotten any detail
on anything other than the C3 project.
Thanks!
Mayan
David B Lightstone
"Uncle Bob (Robert C. Martin)"
news:mk47ou8646jto1l7h...@4ax.com...
> It is remotely possible that on (or about) Sat, 14 Sep 2002 15:53:08
> GMT, "David B Lightstone" <david.lightst...@prodigy.net>
> might (or might not) have written:
>
> >Somehow, someone, (that's you Ronn), thinks, the only way an individual
can
> >understand the implications of new ideas (or even bad old one) on their
> >daily activities, is via experimentation. Sorry to upset your apple cart
> >Ronn, but as long as the extrapolation is not excessive, it can be done.
> >Human beings have been doing it for a rather long time.
>
> Yes, they have. They extrapolated that since feathers fell slower
> than rocks, heavy things fall proportionally faster than light things.
> That extrapolation lasted two thousand years.
>
> Extrapolation of this kind is called -- guessing. Sometimes it
> works, sometimes it doesn't. If you want to *know* something, you
> have to do the experiments.
Oh, I was hoping we could avoid using such loaded words, guessing ,
judgement, what is the difference?
Anyhow if you need absolute certainty, then you would be paralized with
inaction.
Some people don't need absolute certainty. I suspect that you like to
consider yourself to be one such person.
If you need to determine if you are extrapolating excessively, an
experiment might be useful. Is there any chance that excessive
extrapolation/guessing/judgement will to occur?
I noticed that you snipped the question from the original post. I guess
that means you would prefer that it be ignored.
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
Here's a good place to start, it's an old and incomplete list:
http://c2.com/cgi/wiki?ExtremeProgrammingProjects
Then there's Symantec:
http://www.sdmagazine.com/documents/s=2279/sdm0201a/0201a.htm
Workshare:
http://www3.workshare.com/news/ne_pressreleases_view.asp?pressID=27
Escrow.com, Sabre, Qwest, and loads of others.
Then you can go to the various Job referral web sites like Monster and
do a search for job postings that include Extreme Programming.
Go to the XP/Agile universe web site (http://www.xpuniverse.com/home)
and scan the papers to get some ideas of the companies doing XP. Do
the same for the XP2002, XP2001, and XP2000 sites.
http://www.xp2002.org/prog_full.html
http://ciclamino.dibe.unige.it/xp2000/XP2001.html
http://ciclamino.dibe.unige.it/xp2000/
And keep watch on the XP2003 site:
http://www.xp2003.org
Next, take a look at the Extreme Programming Yahoo Group:
http://groups.yahoo.com/group/extremeprogramming/
And there are a wealth of other resources like that.
There were well over 350 people at XP/Agile Universe this year -- up
by more than 100 over last year. There were many companies
represented there that were doing XP.
Peter Harrison
> Anyhow if you need absolute certainty, then you would be paralized with
> inaction.
> Some people don't need absolute certainty. I suspect that you like to
> consider yourself to be one such person.
>
> If you need to determine if you are extrapolating excessively, an
> experiment might be useful. Is there any chance that excessive
> extrapolation/guessing/judgement will to occur?
The issue here is that there are people actually using Agile principles, and
that the initial propositions have been determined by people using Agile
methods in the real world by experience.
> XP (probably) works very well when developing
> 1. programs under 60klocs/year
In other words it doesn't work on large projects. The assumption here is
that you can't break large projects into smaller sub projects. There is
quite good statitical evidence that larger projects are more prone to
failure, so breaking them up is good practise regardless of methodology.
> 2. teams containing skewed towards novices/juniors
Actually the reverse in my experience. Skilled developers I have worked with
suit pair programming well, and have the discipline. I have found juniors
need to have disipline forced on them to stay in pairs and to write unit
tests. They easily slip into bad habits.
> 3. business applications (data-processing, UI et.al.)
The companies using XP in New Zealand I know of are from all kinds of
industry. One of the best known XP shop is actually a manufacturing control
company.
> 4. reasonably mutating specs.
Perhaps true in theory, although I have never been on a project with perfect
requirements and specifications. In fact static specifications makes the
assumption of perfect requirements definition and a perfect system analysis
and specification. In my experience such a beast is a myth.
> 5. moderate correctness requirements
Are we saying here that a project that has grossly incorrect requriements
can succeed? Clearly having requirements that are at least moderatly
correct is a nessesity regardless of methodology.
6. (only weakly connected) OO oriented development
Agile methods are not really tied to OO at all. Some concepts around
refactoring and testing obviously apply to OO principles better than
structured or functional programming. However I don't think OO is a
requirement when doing XP/Agile.
ma...@sandbridgetech.com
would inhibit programmer development and then asked:
[An exercise to the reader: ask yourself
- Do I want to write things like the Linux kernel? Apache web server?
- Can I currently write programs of this kind?
- Will XP give me the programming ability to do so?
Someone said that XP was being used to do things like this.
I asked for examples.
Robert Martin was kind enough to give me some leads, and I spent some
time following them up.
> >"Uncle Bob (Robert C. Martin)" wrote:
>
> >> There are *lots* of very serious projects that are currently using XP.
> >> These projects span many different industries and many different
> >> environments.
<snip>
> >>
> >
> >Excellent! Are there any names, references etc. that you are free to
> >give? It would be nice to get some info from the trenches - or even an
> >idea of what XP is being used for. So far, I haven't gotten any detail
> >on anything other than the C3 project.
>
Here's a summary of my [incomplete] research.
- only one write up that really got into the war stories [IrrsProject]
- only one company doing something hard [Sparta], and one possible
[Omnigon]
- it is NOT clear that Sparta is using XP _at_all_ or what they are
using it for.
Most companies are doing what I'd call "middle-ware" or "web-ware" for
lack of a better word.
So, I'm still waiting on war-stories or trench-reporting on the use of
XP in hard projects.
Mayan
-----
> Here's a good place to start, it's an old and incomplete list:
> http://c2.com/cgi/wiki?ExtremeProgrammingProjects
OK:
AdrenalineGroup (Washington DC, Austin TX):
- mostly web stuff; servlets, websites, server side Java stuff
- nothing about XP practices/experiences
BabbleNet (Vancouver, Canada)
http://alphaworks.ibm.com/aw.nsf/bios/babblenet
- peer-to-peer chat
- 7 people
- mixed development [not everyone used XP; probably 1/2]
- non-commercial
ChryslerComprehensiveCompensation
- payroll
- XP developed here
- discontinued
CsXpCompanies (Colorado Springs XP Companies)
channelpoint
- web stuff; servlets
- out of business
sparta
- military support stuff; probably fairly sophisticated systems
- nothing about the use of XP
DoIt
- distributed objects [OO+CORBA? Some java thrown in]
- nothing about experiences with XP
EvantSolutions (San Francisco)
- web services [web-based merchandising solutions; middleware]
- nothing about experiences
- CTO (who seemed to be their XP cheerleader) got kicked out
GrainMonitorProject (Boston area)
- mobile spectrometer
- nothing about experiences
- project cancelled
HpSoapProject
IrrsProject
- excellent write up.
- not clear what they were doing
- small project (3 people)
LockheedMartinResearchAndDevelopment -- XP with PowerBuilder 7, even
- not clear what they are up to. [probably middleware].
-
NexMedia -
- out of business
OmnigonInternational - eXtreme like no project ever before or again...
- protein folding/genome searching/financial industry [data mining
apps?]
- were building clusters linked by ATM switches before that.
- no info on their XP experiences
ProductSight
- product development support?
- no mention of XP anywhere on their web site [have they abandoned it?]
No time to go through the rest.
> http://www3.workshare.com/news/ne_pressreleases_view.asp?pressID=27
looked at that; interesting; not very stressful though.
> Go to the XP/Agile universe web site (http://www.xpuniverse.com/home)
> and scan the papers to get some ideas of the companies doing XP
Did; couldn't figure out much - mostly consultants and consulting
houses.
ma...@sandbridgetech.com
Peter Harrison wrote:
> > XP (probably) works very well when developing
> > 1. programs under 60klocs/year
>
> In other words it doesn't work on large projects. The assumption here is
> that you can't break large projects into smaller sub projects. There is
> quite good statitical evidence that larger projects are more prone to
> failure, so breaking them up is good practise regardless of methodology.
Good idea; unfortunately you till have to deal with integration issues.
And some programs are not really amenable to that kind of factoring.
> > 2. teams containing skewed towards novices/juniors
>
> Actually the reverse in my experience. Skilled developers I have worked with
> suit pair programming well, and have the discipline. I have found juniors
> need to have disipline forced on them to stay in pairs and to write unit
> tests. They easily slip into bad habits.
What is your definition of skilled? [Productivity? Design Skills?
Experience?]
> > 3. business applications (data-processing, UI et.al.)
>
> The companies using XP in New Zealand I know of are from all kinds of
> industry. One of the best known XP shop is actually a manufacturing control
> company.
Is there a reference? Do they have some war-stories written up? What do
they do?
> > 4. reasonably mutating specs.
>
> Perhaps true in theory, although I have never been on a project with perfect
> requirements and specifications. In fact static specifications makes the
> assumption of perfect requirements definition and a perfect system analysis
> and specification. In my experience such a beast is a myth.
Agreed. However there is a large variation from - "develop me a web
site, I don't know what it will look like" to "implement the IEEE 802.11
MAC layer"
> > 5. moderate correctness requirements
>
> Are we saying here that a project that has grossly incorrect requriements
> can succeed? Clearly having requirements that are at least moderatly
> correct is a nessesity regardless of methodology.
Correctness in the sense of how much the program has to be tested. Web
app breaks - no biggy; shuttle software breaks - OOPS!
> 6. (only weakly connected) OO oriented development
>
> Agile methods are not really tied to OO at all. Some concepts around
> refactoring and testing obviously apply to OO principles better than
> structured or functional programming. However I don't think OO is a
> requirement when doing XP/Agile.
Agreed.
Mayan
Phlip
> - only one company doing something hard [Sparta], and one possible
> [Omnigon]
> - it is NOT clear that Sparta is using XP _at_all_ or what they are
> using it for.
>
> Most companies are doing what I'd call "middle-ware" or "web-ware" for
> lack of a better word.
Again, most projects in the industry in general do those things.
> So, I'm still waiting on war-stories or trench-reporting on the use of
> XP in hard projects.
Are you familiar with the meaning and purpose of an "NDA"?
--
Phlip
http://www.greencheese.org/PhilosophyBrethrenThree
-- DARE to resist drug-war profiteering --
John McClenny
ma...@sandbridgetech.com says...
> Ron, I think you're missing the point - my claim was that XP would
> inhibit programmer development (after a point, probably 1-2 years for a
> good programmer). You *personally* have a lot of programming skills. But
> I will bet that you picked 90%+ of them up in environments other than
> XP.
I came in late here. I don't understand why you think that getting
exposed to a wide range of programming partners (including the most
senior) as XP can promote would inhibit your development as a programmer?
In what way does working solo improve your skills faster than working
paired?
As a total aside, as a pointy headed manager, I would rather have a group
with higher than average skills than one genius and a bunch of morons :).
The star system has failed miserably in many of the projects I have been
involved in and I find it more important to increase as many peoples
skills as possible. I haven't used XP, but don't understand how a system
that lets me encourage skill sharing and mentoring can be detrimental.
Unless, of course, you just want to maximize your skills relative to your
peers by setting up a system that discourages their improvement :).
Doc
Peter Harrison
> Good idea; unfortunately you till have to deal with integration issues.
> And some programs are not really amenable to that kind of factoring.
The NZ Police tried a big bang straegy and had a rather public failure.
There were various reasons, but ultimatly there is little good reason not
to 'refactor' large projects into smaller chunks. Yes there are intergration
issues, however if you have unit tests you can work these out pretty
quickly.
> What is your definition of skilled? [Productivity? Design Skills?
> Experience?]
"Skilled" 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
> 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
> 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
> 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
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
> 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
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
> 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
> >> 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
> 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
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)
-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?
Uncle Bob (Robert C. Martin)
-0700, kras...@consultant.com (krasicki) might (or might not) have
written:
>a.) You can think in peace and quiet.
Do you think that XPers never do that? Of course they do.
>
>b.) You can experiment without feeling self-conscious
Do you think that XPers never do that? Of course they do?
XP's rule about pairing does not prevent you from working alone when
you need to work alone. It just says that you can't check in any
production code that was not created by a pair. This is analogous to
saying that you shouldn't check in production code that hasn't been
reviewed.
>c.) If you are not a gifted teacher already there's no pressure to
>become one.
The best way to learn is to teach. Fortunately teaching someone who
wants to learn is not that hard. You don't have to be gifted, you
just have to share a little.
Uncle Bob (Robert C. Martin)
-0700, kras...@consultant.com (krasicki) might (or might not) have
written:
>Skills aren't a sharable commodity. Do great athletes improve the
>*skills* of those around them?
Of course they do.
Uncle Bob (Robert C. Martin)
-0700, kras...@consultant.com (krasicki) might (or might not) have
written:
>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.
If you believe that, then why are you here? If you believe that then
every one of your posts is a waste of time. Like it or not, your
participation in this newsgroup is a form of collaboration. You and I
are pairing right now.
>Spend a day in any school, in Washington, D.C., or reading Agile
>proponents on this newsgroup - some people will NEVER get it.
Let's hope that some eventually do.
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
>Here's a summary of my [incomplete] research.
I suggest you spend a little more time before you write a summary.
Check out the Symantec and Workshare references. Look through the
papers at the various conferences for those companies and
organizations that reported their experiences with XP. Yes, there are
lots of consulting houses, but there are also quite a few real
companies, and even government agencies.
If you don't have the time, I understand. Most of us wouldn't have
the time. However, if you don't have the time, then try not to make
conclusive statements in the absence of data.
Phlip
>>proponents on this newsgroup - some people will NEVER get it.
>
> Let's hope that some eventually do.
I want to know what that crack about schools in DC is all about.
--
Phlip
http://www.greencheese.org/LucidScheming
-- "He who has had, has been, but he who hasn't been,
has been had" - Stanislaw Lem --
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> It is remotely possible that on (or about) Sat, 14 Sep 2002 23:19:13
> -0400, ma...@sandbridgetech.com might (or might not) have written:
>
> >Here's a summary of my [incomplete] research.
>
> I suggest you spend a little more time before you write a summary.
> Check out the Symantec and Workshare references.
I did. Small; web-based. [see below for why I'm discounting them]
> Look through the
> papers at the various conferences for those companies and
> organizations that reported their experiences with XP.
Looked at some of them. None relevant.
> Yes, there are
> lots of consulting houses, but there are also quite a few real
> companies, and even government agencies.
I am not asking what kinds of companies are doing XP work - I believe a
lot of them are, and successfully. What I am asking is anyone using XP
for large size/high complexity/high reliability problems. To be more
specific - stuff like optimizing compilers, OS kernels, fly-by-wire
systems, data-base kernels etc. These are typically characterized by
requiring:
- a higher requirement for testing than I believe TDD/test-first will
provide
- a higher complexity, which I believe will force an upfront design
phase
- a large size, which will inhibit refactoring
- a higher performance requirement, which will inhibit the use of OO
techniques.
I have not been able to find a single example. And I have asked and
looked. I have found no evidence of any company doing this kind of
stuff.
One person claims that they are working on such a system. I've looked at
both protein folding and at data mining before, and done some work in
similar problems (signature detection of various kinds, molecular-level
modelling, simulated annealing for CAD, etc.). Claiming that that stuff
is high-complexity to implement is a bit of a stretch (the algorithms
are somewhat interesting, on the other hand).
Another person claims that blizzard is using XP. I looked at their
web-site. Their job ads & FAQ make no mention of XP. Clearly, if they
are using XP, they don't stress it.
> If you don't have the time, I understand. Most of us wouldn't have
> the time. However, if you don't have the time, then try not to make
> conclusive statements in the absence of data.
*If* I can find no evidence of it being used *anywhere* outside
middle-ware/business development/web-ware, then it does tend to support
a thesis that XP isn't being used for any high-complexity/large-size
problems.
It should be easier for someone who has been plugged into the XP
community for a long time to come up with an example of a single company
that is doing this kind of work. If you or Ron Jeffries or someone else
from this group can't think of anybody, I'm going to be hard put to find
someone that is doing high-complexity/large-size work with XP.
I had been hoping to get a web-accessible write-up on the use of XP in a
systems house for developing one of these kinds of systems. At this
point, I'll settle for:
- a pointer to a paper I can get (I'll buy the magazine/conference
proceedings if I have to)
- a pointer to a person who is doing this kind of stuff whom I can ask
questions of (I'll try and e-mail him offline)
Thanks
Mayan
--------
P.S. I was wondering why you had given me all those references. I looked
and realized that the original question had been obscured by a lot of
follow-ups. And maybe that question wasn't even properly phrased at
first....
ma...@sandbridgetech.com
krasicki wrote:
> Skills aren't a sharable commodity. Do great athletes improve the
> *skills* of those around them?
> 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.
And a lot of people disagreed with him. I do, too.
However replace skill with *talent* and he starts making sense.
You learn skills; but talent is something innate.
For instance, you can train yourself to play *good* sports; but you have
to have something extra to get to the very top - this is a talent. It
might be height, or hand-eye co-ordination or something else. But it
will be there.
I won't go into the debate about the nurture vs. nature debate about
talent. Either way, by the time people reach adulthood their talents are
pretty fixed.
In the context of this argument, a person can be trained (via pairing or
whatever method you prefer) to be a good programmer. But the best
programmers have an extra something. That you can't acquire by training.
Mayan
Ron Jeffries
>*If* I can find no evidence of it being used *anywhere* outside
>middle-ware/business development/web-ware, then it does tend to support
>a thesis that XP isn't being used for any high-complexity/large-size
>problems.
My intent here is to shed a bit of light on how XP might apply to some of the
areas you mention.
Absence of evidence isn't evidence of absence. However ...
1. XP is not a large- team process, and while individual subteams might use XP,
the entire process would need some additional form of coordination (such as an
outer planning game) that isn't described in the XP literature. So if by
large-size you mean large numbers of people, you're not likely to find anything.
The largest number of developers on a single XP project that I know of was at
Tubmleweed: they had over 30 programmers on the project.
2. XP is being used in some high-reliability applications such as embedded
medical devices, and telecomms embedded stuff (cell phones and the like). You
hypothesize elsewhere that such things would call for more testing than just
XP's starting prescription. That is correct. XP is a starting point, not an
ending point, and most XP teams extend their practices where their situation
demands.
3. I'm not aware of any teams doing compilers or operating systems using XP, but
having done both, I'm quite sure that they could be done with XP, and the ones I
did (at least) would have benefited from it, even though they were successful
both technically and in the market.
4. Elsewhere you dismissed Symantec as a "web application". I think Bob was
meaning that you need to look at what Symantec is really doing with XP: they
have more than one XP project going, and others are lots more like shrink-wrap
products and are quite complex. I don't think anything is published on those, so
they probably don't serve your need to find published material. Yet they are
there.
All this aside, absence of evidence isn't evidence of absence, and absence of
such projects wouldn't be evidence that such projects couldn't be done using XP.
I've done a lot of projects, and a lot of XP. I think I know a fair amount about
both XP and about complex projects. At the scale of team size where XP is aimed
(around a dozen developers) I could and would use XP without question -- though
not without modification. I would /always/ modify it to the real situation, as
the situation revealed itself.
I'm frankly not clear what you're trying to "prove". It seems to be "XP can't be
used on complex projects" or "XP would have to be modified on complex projects",
and you seem tob e trying to "prove" it by not finding evidence.
I'm not trying to prove anything at all at the moment, but I'm here to report
that XP certainly would want to be modified on complex projects, as it generally
is on any real project, and that it is my experienced opinion that it could be
used on complex projects. But it's just opinion, I haven't used it yet on any
operating systems or similar things.
I'd tell you that payroll is more complex than operating systems -- and it is --
but you wouldn't believe me. So I won't go there. ;->
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.
ma...@sandbridgetech.com
John McClenny wrote:
>
> 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?
<sigh> this is really not a statement about that XP inhibits your
development; I said it does accelerate your development for the first
1-2 years. It is what comes after that. And its a matter of how good you
want to (and can) eventually become.
Consider - how much would a programmer might learn if he solo'd a major
project (e.g.:
- write a threaded JVM
- port Linux to bare hardware
- develop an event-driven programming layer on top of sockets &
iostreams)
Thats it - solo; no help from anyone. The programmer has to do the
design, the architecture, the learning, the algorithms, the coding, the
debugging & the testing.
When he/she were done he/she'd know a lot about the big picture. He/she
would also have learnt about how to improve their *personal*
productivity [otherwise they would never get the project finished]. They
would know about their strengths and weaknesses [hopefully].
If you don't do anything difficult, you will never grow.
Using XP [or any kind of methodology where they do not have sole
responsibility for large, difficult chunks of code], they may discover
all of these; but if it happens at all, it will be slower.
This is compounded by the fact that XP tends to get used for writing
not-very-challenging programs. (See some of the other threads)
As I have said before - this is not about whether XP allows a team to be
more efficient (depending on the task and capability mix of the team, I
would agree). It is not about whether XP inhibits initial learning (it
doesn't - it accelerates it). It is about whether it slows down good
programmers from becoming great.
BTW: a comment about Mentoring. Learning something by being told about
it is good in the short-term - but, quite often, bad in the long-term.
You may know *what* to do. You probably have not been told *why* and
*where*; but even if you have, you probably don't understand it at a
deep level. And when it is time to break the rule(s) or, if you find
yourself in territory where the rule(s) do not work, you may not know
enough to generate a new rule.
Consider it in your own context - how much have you learnt from doing
large projects by yourself? How much and how fast would you have learnt
in a more relaxed, "nurturing", environment? How much of what makes you
better than other programmers can be taught? How much of it *could* you
have learnt from others?
Mayan
krasicki
> > kras...@consultant.com (krasicki) might (or might not) have
> > written:
> >
> >>Spend a day in any school, in Washington, D.C., or reading Agile
> >>proponents on this newsgroup - some people will NEVER get it.
> >
> > Let's hope that some eventually do.
>
> I want to know what that crack about schools in DC is all about.
No wonder you hate requirements, you can't read.
The sentence reads any school - comma - Washington, D.C. - comma - HEY
we're pairing - OHMYGOD! It's exhilarating - I'm getting lightheaded -
I think I'll sit down and write a WIKI paper called The Idiot and the
Skeptic introduce Extreme Comma Notation and It all sucks.
HooHoo.
ma...@sandbridgetech.com
Ron Jeffries wrote:
>
> 3. I'm not aware of any teams doing compilers or operating systems using XP, but
> having done both, I'm quite sure that they could be done with XP, and the ones I
> did (at least) would have benefited from it, even though they were successful
> both technically and in the market.
Excellent: lets talk about the following problem: write an optimizing
back-end for a C compiler (assume we purchased the front-end from
someone). How would we use XP, or adapt XP to it?
Some problems with compiler back-ends:
- its fairly clear what has to be done (core
{intermediate-language/instruction
selection/register-allocation/code-generation} + set of optimizations);
its fairly clear what order they have to be done in (first the core,
then a particular sequence of optimizations)
- you don't really need customer input. Having a customer around doesn't
help.
- you can't demo very much till you have a substantial portion of the
code written - the core (say about 30-60klocs) - no small (initial)
release
- you had better get your IL (intermediate language) data-structures
right - if you pick ASTs or 3 or 4 address form, you will do fine for
the basic "dragon-book" optimizations, but later on you will either run
into severe problems doing more advanced optimizations, or you will have
to rewrite your entire code base [probably about 100-150klocs at this
time]. Is this BUFD?
- you had better think of performance up front. Toy programs are easy;
but a compiler has to be able to handle huge 100kloc+ single functions.
Many heuristics are N^2 or N^3. Both run-time efficiency and memory
usage end up being concerns. You can't leave optimization till the end -
you have to keep it in mind always. It also pretty much determines your
choice of language and programming style.
- TDD may be applicable for some of the smaller optimizations; on the
other hand, for doing something like register-allocation using graph
coloring, or cache blocking - I wouldn't even be able to know where to
begin.
- The basic granule (other than the core) is the optimzation. An
optimization can be small (constant propagation in a single basic block)
or large (unroll-and-jam, interprocedural liveness analysis). The larger
ones take multiple days to be written. Integrating them "often" is
either pointless (you integrate the code, but disable the optimization)
or suicidal (you integrate the code, but it breaks lots and lots of
tests; see below). Best case: integrate once the optimization is done.
- Its not easy to split an optimization into subproblems; so typically
one (programmer/pair) works on an optimization. For the larger ones, if
it needs to be tweaked, or fixed, the unit that wrote it is the best
unit to fix it. The overhead to grok a couple of thousand lines of code
(or more!) vs. getting the original team to fix it is way too high.
- Testing, obviously, is a lot more involved. Not only do we have to
check for correctness, we have to check for "goodness" of the produced
code. Unfortunately, many optimizations are not universally beneficial -
they improve some programs, but degrade others. So, unit testing cannot
prove or disprove the goodness of the implementation of the
optimization; it must be integrated with the rest of the compiler to
measure this. Further, if it degrades performance, it may not be a
problem with that optimization - it may have exposed something
downstream from it.
- Typical compiler test suites involve millions of lines of tests. They
tend to be run overnight, and over weekends on multiple machines. If you
have a badly integrated optimization, you've lost a nights run. And
passing all tests before integration is, of course, an impossibility.
Even a simple "acceptance" set of tests will check barely a small
percentage of the total function in the compiler.
Hmmm.....does this still look a lot like XP to you? I can see that at
least 1/3rd of the XP practices being broken (or at least, severely
bent).
Based on your experience, do you disagree with any of the constraints I
outlined?
Mayan
krasicki
> 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 :)
Me, too, on occasion.
>
> 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).
That's a much longer story but what I was hearing from you is that
simple authoritarianism was the answer and I disagree even though you
may be a gifted exception [and I'm guessing you may be].
There is a management book called, "Management as Performance Art"
that I like and there are more. I also like Deming on the quality
front although many software management people HATE him.
I like to coordinate projects, regardless of my own title, so that
everyone is doing something they enjoy and can grow into and beyond -
Carl Rodgers is the originator of this approach mostly applied in
education and humanistic psychology.
However, many corporate stovepipe empires hate not micromanaging and
making people miserable [to prove they're in charge and to dispense
punishment to those who are outside their social graces]. The very
idea that things are moving along smoothly sometimes threatens
management more than problems because nothing is squeaking at
meetings. To them, this means something's wrong or that they're
losing control.
Everyone is different and I what I really distrust about the Agile
assertions is that all you do is pair, do this sequence, and you are
so much better off. This is not true at all. Gifted and average
programmers have their own biorhythms and given an open environment
find something comfortable for themselves using a cafeteria style
selection of established best practices or new practices.
This needs a longer discussion than I have time for - sorry.
>
> 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.
That is fair. However, I would like to point out that you may lose
very capable individuals who are simply not socialites and in this
profession those are many times the gifted individuals [and I'm not
talking about ego, and so forth]. There is a tradeoff.
> 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.
That too is fair based on your assessment of preferences. One of the
reasons I contract is that I love the diversity of assignments. I
have worked many places where I could have stayed for a career. But
having done what I do I know that good teams can be assembled in a
heartbeat when you have a talented person putting it together.
>
> > 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.
Well, I like that you've moved people better than firing them. And
acknowledging that some can't learn is key. I have been in many
companies where someone is considered indispensible and they are the
biggest bottlenecks of all - huge ego, gatekeeper mentality, refuses
to listen to reason,...
This is a horse of a different color but just as exhausting - people
who learn to manipulate the system.
>
> 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.
Agreed. But the Agile proponents like to make assertions in the field
of magic. That is, something that isn't true in education - pairs
make the very same individuals smarter - magically works in business
just because it's an agile methodology. This is pure fiction.
>
> Agile methods speed up feedback loops all along the development process.
Not true at all. If an Agile design is wrong you start over. If it
doesn't fit the architecture you are hosed. If it goes off to an
unknown destination there is no signpost.
Planning up front works. Designing business models up front works.
Using XP to add 'features' to existing systems works - but it is not
the same thing. Using XP on obvious rapid application development
projects is one flavor of doing exactly the same thing otherwise.
> As a manager, they provide me quicker feedback on the performance of each
> member of the team as well as the overall team.
Regardless of methodology, feedback is only as good as you make it.
> This lets me detect and
> fix performance and interpersonal problems before they have a huge impact
> on either the project or the team.
Interpersonal problems can be avoided by leaving programmers find who
helps them best without slave pairing mechanisms.
> Long feedback loops are the reason
> projects get canceled during year 3 with nothing delivered :(. Short
> feedback loops are goodness in software development.
Nothing stops managers from getting feedback as often as they like in
any methodology I know of. Agile under bad management fares no better
than anything else.
On small projects, Agile may work very well - one happy family. But
on complex projects with multiple masters and complex demands there is
no eveidence this can work or that it can even make sense. [These
'going down in flames' projects are the ones I like to try to rectify
- so many of my observations come from these same trenches - happy
talk just doesn't cut it]
I do enjoy the conversation and respect your needs. I just know that
those needs can be served differently with equal or greater
satisfaction than Agile will ever live up to over time and as field
data comes in.
Keith Ray
Ron Jeffries <ronje...@REMOVEacm.org> wrote:
> 3. I'm not aware of any teams doing compilers or operating systems using XP,
> but
> having done both, I'm quite sure that they could be done with XP, and the
> ones I
> did (at least) would have benefited from it, even though they were successful
> both technically and in the market.
The author of book about writing parsers in Java said on the mailing
list that he developed his code test-first. He sent me his tests when I
asked for them.
<http://www.amazon.com/exec/obidos/tg/detail/-/0201719622/qid=1032188392/
sr=1-1/ref=sr_1_1/104-0894671-3041521?v=glance&s=books>
--
C. Keith Ray
Stephen J. Bevan
> Excellent: lets talk about the following problem: write an optimizing
> back-end for a C compiler (assume we purchased the front-end from
> someone). How would we use XP, or adapt XP to it?
Your original question asking for references to the use of XP on
various projects has expired so I'm following up to this message. The
following is an excerpt from "Benefits of Visibility" by Larry
Constantine which appeared in Computer Language Magazine, 9(2), 1992
(reprinted in Constantine on Peopleware 1995, pp 118-119). It doesn't
directly address the issue of an optimising compiler, only show that
one company did use pair programming in the construction of a compiler
(all typos are mine) :-
It took P. J. Plauger, through, to really teach me about the
benefits of visibility. Shortly after he started Whitesmiths, Ltd.,
I visited him at their New York ``headquarters,'' a small apartment
in Manhattan. Somewhere off in one of the rooms there lurked a
minicomputer, stuffed into a closet in order to keep the clatter
down was a printer, and around what should have been the living room
were scattered several terminals. At each terminal were two
programmers!
Of course, only one programmer was actually cutting code at each
keyboard, but the otherw were peering over their shoulders, doing
those annoying things that New Yorkers are especially schooled in,
namely kibitzing. The room buzzed with a steady stream of questions
about the algorithm or whether an initial value was correct,
suggestions about how to break out of a loop, or drawing attention
to a syntax error or test done in the wrong order or a missing
case. After awhile the two programmers would switch places, and the
one at the keyboard would become the professional nudge.
I speculated about cash flow problems being the root of their
shortage of hardware, but Plauger assured me that this was thier
chosen mode for working. Pretty inefficient, huh? Nope. Having
adopted this approach, they were delivering finished and tested code
faster than ever. A closer look showed why. The code that came out
the back of these two-programmer terminals was nearly 100% bug
free. Not only did it have fewer defects, but it was better code,
tighter and more efficient, having benefited from the thinking of
two bright minds and the steady dialogue between trusted
terminal-mates. I came to think of this model for programming
teamwork as the ``Dynamic Duo''. The principle operating here is
very broad: Increasing work visibility leads to increased quality!
Two programmers in tandem is not redundancy; it's a direct route to
greater efficiency and better quality.
That's the end of the mention of pair programming, it continues on
with some views about ``pair learning'' :-
The same principle applies to learning. Most people -- not all, but
most -- learn more rapidly in small groups than they do alone. This
is even true of many diehards who are convinced that they can't larn
that way or who hate to work in groups. Discussion brings up issues
and ideas that might never have occurred to the isolated
individual. Peres can often explain an interpret difficult concepts
when the instructor cannot. New approaches emerge from the dialogue
itself. Perhaps most basically, students in groups learn from each
other, not just from an instructor or textbook. It's one of the
reasons I nearly always use project and study teams in the workshops
and seminars that I lead.
John McClenny
kras...@consultant.com says...
> John McClenny <spa...@bebu.com> wrote in message news:<MPG.17eefa13d...@news.supernews.com>...
> > 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).
>
> That's a much longer story but what I was hearing from you is that
> simple authoritarianism was the answer and I disagree even though you
> may be a gifted exception [and I'm guessing you may be].
One of the management challenges in projects involving groups of
programmers is keeping everyone (reasonably) happy and challenged.
Given that we have a range of personalities and experience levels
involved, how do we keep the more dominant personalities from grabbing
all of the fun work?
If we have a happy team that is used to working together and understands
that the rewards are based at least partially on team success, then the
team will tend to manage itself and divy up the work in a fair manner.
However, sometimes we end up with a dominant personality who wants all of
the fun stuff. At this point, I have had to referee to make a more
equitable distribution of work. The dominant personality may not be the
best programmer, just the loudest:).
> There is a management book called, "Management as Performance Art"
> that I like and there are more. I also like Deming on the quality
> front although many software management people HATE him.
>
> I like to coordinate projects, regardless of my own title, so that
> everyone is doing something they enjoy and can grow into and beyond -
> Carl Rodgers is the originator of this approach mostly applied in
> education and humanistic psychology.
>
> However, many corporate stovepipe empires hate not micromanaging and
> making people miserable [to prove they're in charge and to dispense
> punishment to those who are outside their social graces]. The very
> idea that things are moving along smoothly sometimes threatens
> management more than problems because nothing is squeaking at
> meetings. To them, this means something's wrong or that they're
> losing control.
There are a lot of bad managers out there, but part of the problem is
that the tools for running software projects are crude. Given that many
organizations are still using waterfall development models, even a very
micromanaging manager only has a very slight clue about the actual status
of the project. Agile methods would appear to continually provide a
clear project state. This alone has tremendous value to a corporation.
> Everyone is different and I what I really distrust about the Agile
> assertions is that all you do is pair, do this sequence, and you are
> so much better off. This is not true at all. Gifted and average
> programmers have their own biorhythms and given an open environment
> find something comfortable for themselves using a cafeteria style
> selection of established best practices or new practices.
> That is fair. However, I would like to point out that you may lose
> very capable individuals who are simply not socialites and in this
> profession those are many times the gifted individuals [and I'm not
> talking about ego, and so forth]. There is a tradeoff.
Software development, on most projects, is a team game. Forcing people
to work together can help the shy individuals to develop better social
skills and to learn to enjoy interaction with other people. Using gifted
people to mentor junior people allows them to show off their superior
knowledge and talent by sharing it with a more junior person.
> > > 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.
>
> Well, I like that you've moved people better than firing them. And
> acknowledging that some can't learn is key. I have been in many
> companies where someone is considered indispensible and they are the
> biggest bottlenecks of all - huge ego, gatekeeper mentality, refuses
> to listen to reason,...
Which is one of the reasons that pairing has some attraction to me - the
cross-training that people get reduces the leverage that a key but
uncooperative person has.
It isn't that people can't learn, it is that some people are inherently
more talented programmers than others. You try to match talents to jobs.
> > Agile methods speed up feedback loops all along the development process.
>
> Not true at all. If an Agile design is wrong you start over. If it
> doesn't fit the architecture you are hosed. If it goes off to an
> unknown destination there is no signpost.
If a traditional design fails I cancel the project because we are 18
months into it. I would rather have requirement, design, code, and
customer acceptance failures as early in the project as possible so they
can be fixed as early as possible. I would rather have a lot of little
failures rather than a global failure at the end.
I don't really believe that Agile developers don't have an architecture.
Experienced people have a set of architectural patterns to pick from and
most problems fall into one of these sets. They just don't write it down
:).
> Planning up front works. Designing business models up front works.
Then why do so many software projects fail? We don't have a set of
techniques that consistently result in project success. Agile design
might not be the entire answer, but as a set of tools to enhance or
replace existing methods, it IS important.
> > As a manager, they provide me quicker feedback on the performance of each
> > member of the team as well as the overall team.
>
> Regardless of methodology, feedback is only as good as you make it.
So, you would rather spend 5 hours a week in status meetings and writing
status reports? In normal project management, the 90% complete problem
is most painful. With shorter deliverable cycles, it is either complete
or incomplete.
> > This lets me detect and
> > fix performance and interpersonal problems before they have a huge impact
> > on either the project or the team.
>
> Interpersonal problems can be avoided by leaving programmers find who
> helps them best without slave pairing mechanisms.
Many programmers will NEVER ask for help. They will struggle forever
with something that one of their peers know how to solve.
>
> > Long feedback loops are the reason
> > projects get canceled during year 3 with nothing delivered :(. Short
> > feedback loops are goodness in software development.
>
> Nothing stops managers from getting feedback as often as they like in
> any methodology I know of. Agile under bad management fares no better
> than anything else.
But how do I KNOW if the status is any good? The quality of status
information gathered from programmers in often poor. If I have little
pieces of functionality along with little pieces of test, I KNOW if that
piece is complete.
> On small projects, Agile may work very well - one happy family. But
> on complex projects with multiple masters and complex demands there is
> no eveidence this can work or that it can even make sense. [These
> 'going down in flames' projects are the ones I like to try to rectify
> - so many of my observations come from these same trenches - happy
> talk just doesn't cut it]
We divide large projects into smaller chunks all of the time - look at
many n-tier designs. Given an overall, hand-waving level of
architectures and interfaces between pieces, Agile should work fine
within each piece.
> I do enjoy the conversation and respect your needs. I just know that
> those needs can be served differently with equal or greater
> satisfaction than Agile will ever live up to over time and as field
> data comes in.
So what existing techniques work? :)
>
Hoff, Todd
> Many programmers will NEVER ask for help. They will struggle forever
> with something that one of their peers know how to solve.
And you have to ask why so many projects fail?
--
It's only when your cage is rattled do you realize you are in a cage.
Tom Plunket
> - a higher requirement for testing than I believe TDD/test-first
> will provide
I don't believe that TDD is meant to suggest that it can be the
sole means of testing your application.
> Another person claims that blizzard is using XP. I looked at
> their web-site. Their job ads & FAQ make no mention of XP.
> Clearly, if they are using XP, they don't stress it.
In games, it is typically not the methodology that gets people
interested in the company. Indeed, most games development is
still done Code & Fix.
Anyway, I made the statement that they are using it. I gained
this information from a person who worked there, and I do not
know how to contact this person for more information. I do not
work there either, but this person said that they were having
great success with it and were trying to "enlighten" the other
groups. Actually he didn't say enlighten, he in fact downplayed
the whole XP point except to say something to the effect of,
"yeah we do all of the practices most of the time."
> *If* I can find no evidence of it being used *anywhere* outside
> middle-ware/business development/web-ware, then it does tend to
> support a thesis that XP isn't being used for any
> high-complexity/large-size problems.
You should emphasize the 'no evidence' also, and since you have
had some, however shaky, evidence that it *is* being practiced
outside of these areas, it would behoove you to accept that it
may in fact be happening.
> It should be easier for someone who has been plugged into the XP
> community for a long time to come up with an example of a single
> company that is doing this kind of work.
I'm not plugged in, but I gave an example. You need to have an
example and verifiably provably correct documentation that these
people are doing it? Jeez, steep requirements!
> I had been hoping to get a web-accessible write-up on the use of
> XP in a systems house for developing one of these kinds of
> systems.
People in development typically don't feel it necessary to
evangelize what they're doing on a website. My employer
expressly prohibits it. What makes you think that people working
in the web development group of a company would take the time to
extoll the virtues of the methodologies being used by the
development team?
-tom!
Phlip
> I don't believe that TDD is meant to suggest that it can be the
> sole means of testing your application.
Everyone actually trying to learn here knows it's a design system. You
don't tell a QA team to assault your unit tests with code coverage analysis
techniques, for the same reason as you don't tell them to assault your UML
diagrams with the same coverage analysis. If they need coverage analysis,
they write this in parallel with the team.
> In games, it is typically not the methodology that gets people
> interested in the company. Indeed, most games development is
> still done Code & Fix.
The games with the best code, such as the well-known Doom and Quake lineage
from Id Software, were still done CNF. They survived because a lucky genius
did the coding, fixing, and significant refactoring. I'd rather not rely on
luck.
> Anyway, I made the statement that they are using it. I gained
> this information from a person who worked there, and I do not
> know how to contact this person for more information. I do not
> work there either, but this person said that they were having
> great success with it and were trying to "enlighten" the other
> groups. Actually he didn't say enlighten, he in fact downplayed
> the whole XP point except to say something to the effect of,
> "yeah we do all of the practices most of the time."
This sometimes teeters on the speaker's awareness of the techniques. "Yeah,
we never document our designs, and we just write what we feel like, but we
never test or pair" is not XP. So qualify your future Blizzard citations.
> People in development typically don't feel it necessary to
> evangelize what they're doing on a website. My employer
> expressly prohibits it. What makes you think that people working
> in the web development group of a company would take the time to
> extoll the virtues of the methodologies being used by the
> development team?
One could also enrole in the XP mailing list and ask the 3,000 people there
to have a bragging contest over the size and complexity of their agile
projects. I'd be curious to see who wins.
--
Phlip
http://www.c2.com/cgi/wiki?DevNull
-- "Probably one of the toughest times in anyone's life is when
you have to kill someone you love because they'r the Devil"
--Emo Phillips --
Mike Dawn
have develop software for hardware that put in airplane cockpit, oil
drill, and airline schedule system. XP can be hack job in a way. XP
also good when you design software where the customer have no set of
requirement. XP do well in Web development, and Windows general
applications.
If you design software to put machines that can kill people, you
better think twice about design software. This way I got a computer
engineer. They always teach me to protect people first.
Mike D.
ma...@sandbridgetech.com wrote in message news:<3D85C2BD...@sandbridgetech.com>...
Phlip
> I belived XP is good for some projects, but other will not work. I
> have develop software for hardware that put in airplane cockpit, oil
> drill, and airline schedule system. XP can be hack job in a way. XP
> also good when you design software where the customer have no set of
> requirement. XP do well in Web development, and Windows general
> applications.
>
> If you design software to put machines that can kill people, you
> better think twice about design software. This way I got a computer
> engineer. They always teach me to protect people first.
Top 10 things Dennis Nedry, the programmer in the 1993 movie "Jurassic
Park", got wrong:
10. Tries to steal tissue samples instead of just software.
(Duh! In bioinformatics the software is the hardest part!!)
9. Customer Acceptance Tests? H'yeah, right!
8. Rebuilds took too long (used as a reliable excuse during sabotage)
7. Colocated in the operations center
6. Used Unix, but with a dramatic 3d view of the file system instead
of a shell
5. One programmer to do the databases AND the surveillance systems AND
the lab AND the snack bar AND the security perimeter AND the
bioinformatics >AND< fill the system with backdoors, timebombs,
animated tripwires & trojan horses?? Someone on the 'net pointed out
he should get the Programming God of the Century Award...
4. Rolled a list of thousands of small glitches up the hill in front
of him (in the book version)
3. No stock options (the greed motivation)
2. Long hours (and too many Jolt cans)
1. No pair
--
Phlip
http://c2.com/cgi/wiki?DevNull
"Remember always that you not only have the right to be an
individual, you also have an obligation to be one." -- Eleanor
Roosevelt
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
>
>
>"Uncle Bob (Robert C. Martin)" wrote:
>>
>> I suggest you spend a little more time before you write a summary.
>> Check out the Symantec and Workshare references.
>
>I did. Small; web-based. [see below for why I'm discounting them]
The Symantec project is their network security manager. It is neither
web based nor small. The team is on the order of 70 people,
subdivided into three different teams in two different locations.
This is a big project for a big company.
The workshare project is a collaborative writing tool used mostly by
the legal industry. It is not web based, and it is not small. The
team is on the order of 20 people, and the project has been going for
some years.
Keith Ray
mik...@yahoo.com (Mike Dawn) wrote:
> I belived XP is good for some projects, but other will not work. I
> have develop software for hardware that put in airplane cockpit, oil
> drill, and airline schedule system. XP can be hack job in a way. XP
> also good when you design software where the customer have no set of
> requirement. XP do well in Web development, and Windows general
> applications.
>
> If you design software to put machines that can kill people, you
> better think twice about design software. This way I got a computer
> engineer. They always teach me to protect people first.
>
> Mike D.
XP is a minimal process, designed for common business-oriented
application development. If you need more, then you need more. No one
said you can't *ADD* to XP.
By the way, XP's short iterations were inspired by a project to build
pacemakers -- hardware and software controlling someone's heart-beat.
Phlip
> No wonder you hate requirements, you can't read.
Frank, you are a pitiable character.
Your fear that your lousy career will get outsourced or something, and you
reek of self-denial over your motivation for attending newsgroups. Please
go find one where anybody agrees with you.
And read this year's OOPSLA schedule.
--
Phlip
http://www.greencheese.org/MakeItSo
-- "The Epiphany of the Epiphenomenon of the Epiphysis"
- some jerk-off maliciously pretending to be Henry Miller --
Richard MacDonald
$S...@newsreader.com:
> John McClenny <spa...@bebu.com> wrote:
>> Many programmers will NEVER ask for help. They will struggle forever
>> with something that one of their peers know how to solve.
>
> And you have to ask why so many projects fail?
>
C'mon. That is 1 of 100+ reasons, and hardly the most important one.
Richard MacDonald
news:3D85BB54...@sandbridgetech.com:
>
> In the context of this argument, a person can be trained (via pairing
> or whatever method you prefer) to be a good programmer. But the best
> programmers have an extra something. That you can't acquire by
> training.
Would you agree with the claim: "A prerequisite for 'that extra
something' is to care about good code"? I don't know for sure, but I do
know that all the great people I work with have that as a basic
requirement for entry into the "elite fraternity". I don't see how one
could do without caring first and foremost.
I've also been pairing lately with a guy who is flat out genius. I was
excited to learn some new skills, so I have spent a great deal of time
analyzing him. What I can say is that of the two basic types of genius (
(1) the "out-of-left-fielder" and (2) "like you and me, just 10 times
better"), he is the latter. (He also has a phenomenal grasp of the
first-principles so he gets everything new immediately. It also means he
tends to start from scratch so he is also the guy we joke can be "2
months behind in a 1 month assignment", but that is another story told
in awe because he can catch up those 2 months in one all-nighter :-)
Anyway, he does what I do, just 10 times better. This is good, because
it means his approach is therefore copy-able. Unfortunately, it requires
having a phenomenal memory and mental model of complex apps (able to
identify in his head and then surf straight to the exact location of a
bug in a complex program 6 months after he last looked at the code), and
a flawless mental stack able to unwind without missing a beat. At my age
its a bit hard to pick up those skills :-) Not sure if the problem was
bad genes, losing too many brain cells in college, or picking an
Engineering degree where "I don't need to memorize no stinking formulas,
I'll always have the book to look it up!" I'll always need a bigger
monitor.
Pardon the ramble. My pair quotes a study that found the only verifiable
difference between ok programmers and great programmers was the size of
one's mental stack, but I have not found any sources.
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> It is remotely possible that on (or about) Mon, 16 Sep 2002 05:01:47
> -0400, ma...@sandbridgetech.com might (or might not) have written:
>
> >
> >
> >"Uncle Bob (Robert C. Martin)" wrote:
> >>
> >> I suggest you spend a little more time before you write a summary.
> >> Check out the Symantec and Workshare references.
> >
> >I did. Small; web-based. [see below for why I'm discounting them]
>
> The Symantec project is their network security manager. It is neither
> web based nor small. The team is on the order of 70 people,
> subdivided into three different teams in two different locations.
> This is a big project for a big company.
It is small - according to the article, the most successful of the teams
(Orca) had about 17-25 people involved, who produced 5000 loc of Java (+
4000 loc test code). I went back and read those numbers multiple times -
5 kloc falls into the category of *tiny*, not small.
BTW: 7+ man-years to produce 5 klocs of tested code? Is 700
loc/programmer year considered a success story at Symantec?
Mayan
----
Lets see according to the article you pointed me to:
[http://www.sdmagazine.com/documents/s=2279/sdm0201a/0201a.htm]
Quotes:
[w.r.t Orca] " Up to this point, they'd only heard the high-level
concepts: this is Web-based, it's XML-based, it's response management."
" 25 of the 120 people "
" two groups of 10 members each"
" bringing the total to 10 developers, one and a half technical writers,
five QA people and one customer"
"6 months...it was a four-month project"
"a product that's roughly 5,000 lines of Java code, plus another 4,000
LOC in the acceptance and unit tests"
Rubicon: " a product update that is the second XP project at the
American Fork site, isn't having such an easy time."
"Three Months...Orca is now the only XP team at American Fork"
"anticipates restarting the Rubicon team in mid-October"
San Antonio/Jaguar: "The San Antonio team, he says, is slightly smaller
than Orca"
" it was a four-month project"
" 6 months...successfully delivered two smaller (three- to
four-man-month) projects"
Phlip
> It is small - according to the article, the most successful of the teams
> (Orca) had about 17-25 people involved, who produced 5000 loc of Java (+
> 4000 loc test code). I went back and read those numbers multiple times -
> 5 kloc falls into the category of tiny, not small.
An XP project with a 5 to 4 ratio of production to test code lines?
I don't think so...
--
Phlip
http://andstuff.org/CelebrityImpersonations
-- Personally qualified to snub Mensa --
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
>
>
>"Uncle Bob (Robert C. Martin)" wrote:
>>
>> It is remotely possible that on (or about) Mon, 16 Sep 2002 05:01:47
>> -0400, ma...@sandbridgetech.com might (or might not) have written:
>>
>> >
>> >
>> >"Uncle Bob (Robert C. Martin)" wrote:
>> >>
>> >> I suggest you spend a little more time before you write a summary.
>> >> Check out the Symantec and Workshare references.
>> >
>> >I did. Small; web-based. [see below for why I'm discounting them]
>>
>> The Symantec project is their network security manager. It is neither
>> web based nor small. The team is on the order of 70 people,
>> subdivided into three different teams in two different locations.
>> This is a big project for a big company.
>
>It is small - according to the article, the most successful of the teams
>(Orca) had about 17-25 people involved, who produced 5000 loc of Java (+
>4000 loc test code). I went back and read those numbers multiple times -
>5 kloc falls into the category of *tiny*, not small.
>
>BTW: 7+ man-years to produce 5 klocs of tested code? Is 700
>loc/programmer year considered a success story at Symantec?
>
There is, of course, another explanation. I'll leave it to you to
figure out what that is. However, I'll simply add that the
application that teams of 6 implement in 2.5 days at XP Immersion is
about 2000 LOC of Java.
As for your assertions of tininess, etc. Having been there, I can
assure you that you are in error.
Keith Ray
Richard MacDonald <macdo...@worldnet.att.net> wrote:
> Pardon the ramble. My pair quotes a study that found the only verifiable
> difference between ok programmers and great programmers was the size of
> one's mental stack, but I have not found any sources.
Notes on a piece of paper can extend one's mental stack greatly.
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> It is remotely possible that on (or about) Mon, 16 Sep 2002 23:27:47
> -0400, ma...@sandbridgetech.com might (or might not) have written:
>
> >
> >
> >"Uncle Bob (Robert C. Martin)" wrote:
> >>
> >> It is remotely possible that on (or about) Mon, 16 Sep 2002 05:01:47
> >> -0400, ma...@sandbridgetech.com might (or might not) have written:
> >>
> >> >
> >> >
> >> >"Uncle Bob (Robert C. Martin)" wrote:
> >> >>
> >> >> I suggest you spend a little more time before you write a summary.
> >> >> Check out the Symantec and Workshare references.
> >> >
> >> >I did. Small; web-based. [see below for why I'm discounting them]
> >>
> >> The Symantec project is their network security manager. It is neither
> >> web based nor small. The team is on the order of 70 people,
> >> subdivided into three different teams in two different locations.
> >> This is a big project for a big company.
> >
> >It is small - according to the article, the most successful of the teams
> >(Orca) had about 17-25 people involved, who produced 5000 loc of Java (+
> >4000 loc test code). I went back and read those numbers multiple times -
> >5 kloc falls into the category of *tiny*, not small.
> >
> >BTW: 7+ man-years to produce 5 klocs of tested code? Is 700
> >loc/programmer year considered a success story at Symantec?
> >
>
> There is, of course, another explanation. I'll leave it to you to
> figure out what that is.
Perhaps someone can help me: Here is the exact quotes:
[ From http://www.sdmagazine.com/documents/s=2279/sdm0201a/0201a.htm]
Quote 1: (October)
By another measure, Orca today, after six months of development, had
only 14 bugs across 13 [two-week] iterations." This, in a product that's
roughly 5,000 lines of Java code, plus another 4,000 LOC in the
acceptance and unit tests.
Quote 2: (May)
..the Orca developers have divided into two groups of 10 members each...
Quote 3: (August)
...five people have been added to the Orca project, bringing the total
to 10 developers, one and a half technical writers, five QA people and
one customer. Turnover hasn't been an issue—one tester has left to
pursue a microbiology degree, but that's it
So, here was my reading of the quotes:
* Orca is 5kloc of Java + 4kloc of test-code
* the team size was 20 in may, 17 in august [of course it may have
varied in the middle].
* the team spent 6.5 months on the project
The team developed 5k of code in 6 months [note - this is the shipped
product, not all the stuff which they wrote and had to throw
away/rewrite - just the delivered code]. That comes to 10k/year. If I
assume they only had 10 developers on it (ignore QA people, ignore ups
and downs of staffing - though according to quote 3 there wasn't much) -
then that works out to 1k/developer year.
> As for your assertions of tininess, etc. Having been there, I can
> assure you that you are in error.
>
5 klocs is tiny - particularily for a high-level language app in Java.
Even if it was a real-time device-driver program written purely in
assembler, it would at best be small.
And come on - if it takes 15-20 people 6 months to produce
- 5 klocs of code
- in a high-level language
- for a problem that is reasonably well understood (I didn't mention it
- but Orca was an upgrade to an existing product)
that's not a testimonial to *ANY* methodology.
Mayan
----
> However, I'll simply add that the
> application that teams of 6 implement in 2.5 days at XP Immersion is
> about 2000 LOC of Java.
<grin> A 2 kloc problem? in 2.5 days? with *6* people? No distractions,
no meetings, no maintanence activity, just worrying about that one
problem?
If this is considered a big deal then:
- either you start off with an ill-defined problem, and people spend
most of their time understanding the problem
- or the programmers have a more fundamental problem than methodology;
their basic programming skills need sharpening.
Tom Plunket
> This sometimes teeters on the speaker's awareness of the
> techniques. "Yeah, we never document our designs, and we just
> write what we feel like, but we never test or pair" is not XP. So
> qualify your future Blizzard citations.
Sorry. The group was talking about XP, and this guy obviously
knew what he was talking about; I had hoped that if I said they
were apparently doing XP that they had listed the key attributes.
Among those attributes specifically mentioned are PairProgramming
and TestFirstDevelopment. I've been here long enough to know
/that/ much. ;)
-tom!
Tom Plunket
> > Pardon the ramble. My pair quotes a study that found the only verifiable
> > difference between ok programmers and great programmers was the size of
> > one's mental stack, but I have not found any sources.
>
> Notes on a piece of paper can extend one's mental stack greatly.
Ahh, the virtues of virtual memory... The problem I have with
this is that I often misplace the storage. ;)
-tom!
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
>> However, I'll simply add that the
>> application that teams of 6 implement in 2.5 days at XP Immersion is
>> about 2000 LOC of Java.
>
><grin> A 2 kloc problem? in 2.5 days? with *6* people? No distractions,
>no meetings, no maintanence activity, just worrying about that one
>problem?
>
>If this is considered a big deal then:
>- either you start off with an ill-defined problem, and people spend
>most of their time understanding the problem
>- or the programmers have a more fundamental problem than methodology;
>their basic programming skills need sharpening.
Mayan, I wasn't trying to do a pecker check with you. I was making
the point that even in an environment of lecture, uncertainty, and
learning, like XP Immersion, the students can out-do what the article
seemed to be reporting about the Symantec team. The conclusion is
obvious to me, but perhaps not to you. Perhaps there is a K or a zero
missing from the article? Maybe the reporter got it wrong?
I'm a little disappointed in your attitude towards the Immersion
students. They're in a new environment, trying new practices that
they've never used before, working on systems they've never used
before, and source code control they've never used before, working
with people they just met, trying to get their arms around a new
methodology. And they *still* manage to get a couple of thousand
lines of code written in something less than 20 hours of programming.
You may not think that's much of an achievement. You have that right.
On the other hand, I look forward to the day when you are placed in a
similar situation and can dazzle the rest of us.
ma...@sandbridgetech.com
"Uncle Bob (Robert C. Martin)" wrote:
>
> The conclusion is
> obvious to me, but perhaps not to you. Perhaps there is a K or a zero
> missing from the article? Maybe the reporter got it wrong?
You should be able to authoratatively answer that question; after all
"[the author of the article has] been invited by OO guru Robert Martin
to observe how these Symantec engineers tackle the year-long development
of ... Orca."
You should be able to set the article (and us) straight; what did the
article get wrong - was it 50,000 locs of java and 4,000 locs of testing
code? 5000 klocs of Java code?
Or did the author completely mis-understand what her source told her?
So, what are the real numbers?
Mayan
Uncle Bob (Robert C. Martin)
-0400, ma...@sandbridgetech.com might (or might not) have written:
>
>
I don't know. I've never been a big fan of line counting. I am sure,
however, that there is something wrong with the numbers in the
article.
Carlton Nettleton
> >You should be able to authoratatively answer that question; after all
> >"[the author of the article has] been invited by OO guru Robert Martin
> >to observe how these Symantec engineers tackle the year-long development
> >of ... Orca."
> >
> >You should be able to set the article (and us) straight; what did the
> >article get wrong - was it 50,000 locs of java and 4,000 locs of testing
> >code? 5000 klocs of Java code?
> >
> >Or did the author completely mis-understand what her source told her?
> >
> >So, what are the real numbers?
>
of code at Symantec. Even if the numbers are true, what point are you
trying to make? You are such a better coder than Bob Martin and the
rest of the Orca team?
Good for you. Mayan is a better coder. In fact, he is the best coder
of all. Glad we all found that out.
ma...@sandbridgetech.com
Whether I am a decent coder or not is not the point - the fact that an
article states that a 20ish person team produces 5000 loc in 6 months is
a *SUCCESS* is the point.
Consider this: someone comes to you and says: our programmers are great
- they write 500 lines of Java code a year - what would your reaction
be? Admiration for their productivity?
Now, lets imagine that the same someone says that this is a great
improvement over the productivity in their previous project. Now, what
would your reaction be? Astonishment at their improvement?
Further, lets say someone writes all this up in an article and treats
this as a success story. What is *your* reaction to such an article?
:)
Mayan
P.S. I sent an e-mail to the author of that article asking about those
numbers. No response yet.
Phlip
> Whether I am a decent coder or not is not the point - the fact that an
> article states that a 20ish person team produces 5000 loc in 6 months is
> a SUCCESS is the point.
And you believe everything you read?
--
Phlip
http://c2.com/cgi/wiki?SheChangeDesignInTheDatabase
-- Who needs a degree when we have Web e-search engines? --
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > Whether I am a decent coder or not is not the point - the fact that an
> > article states that a 20ish person team produces 5000 loc in 6 months is
> > a SUCCESS is the point.
>
> And you believe everything you read?
>
a) Robert Martin told me to go look at the article
b) Robert Martin was involved in the project
c) Its referred to in the objectmentor website
[http://www.objectmentor.com/processImprovement/xpCaseStudies]
Given that he is one of the more reasonable/rational posters, I assumed
that he both knew what he was talking about and has probably vetted the
article (and the numbers).
So, yes, I believed them.
What reason would you have to disbelieve them? Besides the fact that
they are ludicrous?
Mayan
Phlip
> What reason would you have to disbelieve them? Besides the fact that
> they are ludicrous?
Because the simplest explanation is they are missing a k.
(This is the explanation Robert Martin was waiting to see if you'd admit.)
The more complex explanation is the team feels a ridiculous level of pride
over a ridiculously low productivity metric, and a professional reporter
bought their lame story and wrote it up as if it were a great achievement.
Given two theories and no evidence to distinguish them, go with the
simplest one.
You could actually try to probe the facts (such as by e-mailing the
reporter). Or you could continue to announce you are smarter than everyone
involved with the article. Now that isn't the simplest explanation, but
it's the one most likely to stroke your ego.
--
Phlip
http://www.greencheese.org/PhilosophyBrethrenThree
-- The meetings will continue
until the schedule improves --
ma...@sandbridgetech.com
Phlip wrote:
>
> ma...@sandbridgetech.com wrote:
>
> > What reason would you have to disbelieve them? Besides the fact that
> > they are ludicrous?
>
> Because the simplest explanation is they are missing a k.
Let me add the k to their numbers - 5000 *k*loc.
So, ok - lets see they wrote *5 M* of java code in 6 months using 10
developers - averages to a *million* lines of code a year/developer.
Yeah, thats believable.
> (This is the explanation Robert Martin was waiting to see if you'd admit.)
So - let me get this straight - you find it believable that these guys
averaged 1M loc/year. That works out to 500 loc an *hour* *delivered*
(assuming 40 hour work week) - or 8 lines a minute! Wow! That *IS*
fantastic (in the original sense of the work).
Oh - and I forgot - they must have been pairing. So, its *really* 16
lines a minute! This of course does not include any time for coffee
breaks, meetings, thinking, refactoring. What do you think they were
averaging when they were coding - 1 line a second?
Hmmm...even at 16 lines a minute - do you think they were typing oh 30
words per minute? Sustained. For 6 months. Even with the pairing breaks,
I wonder how much RSI/CTS was prevalent among them. I hope they had a
good medical plan.
> The more complex explanation is the team feels a ridiculous level of pride
> over a ridiculously low productivity metric, and a professional reporter
> bought their lame story and wrote it up as if it were a great achievement.
>
> Given two theories and no evidence to distinguish them, go with the
> simplest one.
And the simpler one is to believe that they produced 5M lines of java
code, in 6 months with 10 developers?
> You could actually try to probe the facts (such as by e-mailing the
> reporter).
Did that - three days ago. No ack. Heck, I even said that on the note
that you're responding to.
> Or you could continue to announce you are smarter than everyone
> involved with the article.
Smarter? Maybe, maybe not. More detail-oriented/concientious/nit-picky -
yes. I _try_ to work out all numbers before I make a statement.
> Now that isn't the simplest explanation, but
> it's the one most likely to stroke your ego.
You tell me what is simpler to believe -- 5k or 5M.
Mayan
Epiphyte
> I am not asking what kinds of companies are doing XP work - I believe a
> lot of them are, and successfully. What I am asking is anyone using XP
> for large size/high complexity/high reliability problems. To be more
> specific - stuff like optimizing compilers, OS kernels, fly-by-wire
> systems, data-base kernels etc. These are typically characterized by
> requiring:
somebody to pay for it
>
> - a higher requirement for testing than I believe TDD/test-first will
> provide
> - a higher complexity, which I believe will force an upfront design
> phase
> - a large size, which will inhibit refactoring
> - a higher performance requirement, which will inhibit the use of OO
> techniques.
>
[...]
>
> *If* I can find no evidence of it being used *anywhere* outside
> middle-ware/business development/web-ware, then it does tend to support
> a thesis that XP isn't being used for any high-complexity/large-size
> problems.
>
My sense is you are bored with businessy-web-stuff. But then, what's
really wrong? PeopleCoders coming down the hall?
Web stuff is really complex when you look at it(ever looked at
weblogic's socket muxer, what's between the listen port and your
servlet?), but if it's the "business folks" perception that it is
just a walk in the park, then we get peoplecoders coming down the
hall wanting your web gig. On the other hand if it is really all
that complex then the business folks would just as soon throw the
problem over the fence. So you're damned either way.
According to Forrester, right now Executives want to spend money on
Dynamic Portals or Business Intelligence software. Those are your
choices, pick one.
Good luck in your search.
Richard MacDonald
news:%_wi9.256$JC7...@newssvr19.news.prodigy.com:
> ma...@sandbridgetech.com wrote:
>
>> What reason would you have to disbelieve them? Besides the fact that
>> they are ludicrous?
>
> Because the simplest explanation is they are missing a k.
>
> (This is the explanation Robert Martin was waiting to see if you'd
> admit.)
What are you talking about, "admit". How can he "admit" something he
doesn't know? Especially when other people claim to be familiar with the
project and don't know the answer either (I'm assuming Robert would just
come out and say it rather than allude to it, if he had the hard facts.)
>
> The more complex explanation is the team feels a ridiculous level of
> pride over a ridiculously low productivity metric, and a professional
> reporter bought their lame story and wrote it up as if it were a great
> achievement.
>
> Given two theories and no evidence to distinguish them, go with the
> simplest one.
I don't think this is an appropriate use of that technique.
> You could actually try to probe the facts (such as by e-mailing the
> reporter).
He did.
> Or you could continue to announce you are smarter than
> everyone involved with the article. Now that isn't the simplest
> explanation, but it's the one most likely to stroke your ego.
>
Where did that come from? Jeez, guys, this is an awful lot of knee-jerk
defensiveness to excuse an article that is possibly missing a k. Mayan
has done the leg work to read the article and email the author. He found
a problem. A missing k (or not) is a rather important issue (funny how
the relevance of an article can rest upon a single letter :-) If someone
knows there is a missing k, come on out and say it. Don't beat around the
bush.
IOW, someone references an article purported to show how great XP is. The
guy actually reads it and finds exactly the opposite. So we get on his
case, whereas we should be embarrassed for not spotting that typo
ourselves and being more careful with our references.
(Of course, if the attitude is a holdover from the poorly chosen title of
this thread, I'm in agreement :-)
Otis Bricker
> Carlton Nettleton wrote:
> >
> > > >
> > > >You should be able to authoratatively answer that question; after all
> > > >"[the author of the article has] been invited by OO guru Robert Martin
> > > >to observe how these Symantec engineers tackle the year-long development
> > > >of ... Orca."
> > > >
> > > >You should be able to set the article (and us) straight; what did the
> > > >article get wrong - was it 50,000 locs of java and 4,000 locs of testing
> > > >code? 5000 klocs of Java code?
> > > >
> > > >Or did the author completely mis-understand what her source told her?
> > > >
> > > >So, what are the real numbers?
> > >
> > I don't think Bob Martin was hired or invited to come and count lines
> > of code at Symantec. Even if the numbers are true, what point are you
> > trying to make? You are such a better coder than Bob Martin and the
> > rest of the Orca team?
> >
> > Good for you. Mayan is a better coder. In fact, he is the best coder
> > of all. Glad we all found that out.
>
> Whether I am a decent coder or not is not the point - the fact that an
> article states that a 20ish person team produces 5000 loc in 6 months is
> a *SUCCESS* is the point.
>
I inferred the answers to the following questions from the article So
I could be wrong but...
Did the product provide the features they were after? Yes.
Was it delivered on time? Yes
Was it delivered on budget? Yes
Was the level of quality acceptable? Yes
I have to ask you, by what measure was this project NOT a success?
LOC is a rather useless statistic. It tends to penalize effective
design and reuse. So even if the numbers are correct, WHO CARES? It
might just mean that the team was very good at removing duplication.
Otis Bricker
ma...@sandbridgetech.com
Otis Bricker wrote:
>
> ma...@sandbridgetech.com wrote in message news:<3D8A8A9A...@sandbridgetech.com>...
>
> > Whether I am a decent coder or not is not the point - the fact that an
> > article states that a 20ish person team produces 5000 loc in 6 months is
> > a *SUCCESS* is the point.
> >
>
> I inferred the answers to the following questions from the article So
> I could be wrong but...
>
> Did the product provide the features they were after? Yes.
> Was it delivered on time? Yes
> Was it delivered on budget? Yes
> Was the level of quality acceptable? Yes
>
> I have to ask you, by what measure was this project NOT a success?
By the most important standard - our pride in ourselves as programmers.
5000 loc, 6 months, 10 developers - thats 1000 loc/programmer/year. Is
that an acceptable standard?
The only reason, IMO, to not be _utterly_ embarassed about producing 4
loc/day is:
- life-critical code
- assembly language device drivers
- you're not developing code, you're really developing *new*, *hard*
algorithms.
> LOC is a rather useless statistic. It tends to penalize effective
> design and reuse.
Yes - it is a gross statistic; you must use it with care. But when it is
4 loc/day, it _is _meaningful. No matter how much design and reuse you
do, if the final product was 5kloc, and you took 60 man-months to
develop it -- I, personally, would be embarassed.
> So even if the numbers are correct, WHO CARES? It
> might just mean that the team was very good at removing duplication.
From where? We're not talking 100,000's of loc, where there is room for
massive trimming - we're only talking 5kloc.
All rhetoric aside - consider the situtation:
- 10 developers
- 5 QA
- 1.5 tech writers
- Java
- reasonably well understood problem
Now, tell me what you think of a team where the final product is 5kloc,
but the team takes 6 months to write it?
Mayan
Phlip
> By the most important standard - our pride in ourselves as programmers.
This is an example of the debate trick called "Absent Proxy". Semantic is not
here, so they cannot counter your "facts", nor discredit your assumptions.
Debating with or against someone who is not here represents bluffing when the
cards in your own hand hold no value.
--
Phlip
http://clublet.com/c/c/why?ZenoBuddhism
"If there were a verb meaning 'to believe falsely,' it would not have
any significant first person, present indicative." -- Ludwig
Wittgenstein
Carlton Nettleton
place of LOC? Perhaps success was defined as little or no defects?
Maybe success was defined as retention rate after the project, i.e.
everyone stayed on? Maybe success was defined as implmenting a
successful change in the corporate culture at Symantec? My point is,
the people involved thought it was a success. You apparently do not
based on what you have judged to be a success. Your prejudices and
misunderstandings of the project's goals still do not disqualify the
project from being successful.
Also, why is it so important how much code a person can write a year?
I thought software developers created software that is easy to
maintain and (hopefully) defect-free, not 10M lines of code? The only
reason why this metric would be of interest is for bragging rights to
other computer geeks and the easily impressed; "I managed a team that
wrote 10M lines of code in one year." Even then, the computer geeks
would be suspicious that the code was buggy and hard to maintain and
you could have just hasve easily told the easily impressed you just
balanced 10M dnacing angels on the head of a pin and gotten the same
reaction.
It seems that your measurement for success is very small and limited.
While LOC might continue to be valid measurement for success, I feel
maintaining a customer relationship is more important than X LOC.
Delivering to a 10M LOC product to a customer in a year, and then
watch them cancel the contract is no success to me. However, it seems
that your experience says I am wrong.