article on "mutual programming"
Gerold Keefer
we set up an article on an approach we call "mutual programming" at
http://www.avoca-vsm.com/Dateien-Download/MutualProgramming.doc .
the approach seeks to combine element of the PSP and XP in away
that keeps the developers motivated and still contains necessary
formalism.
comments are welcome.
best regards,
gerold
--
=====================================================================
AVOCA GmbH - Advanced Visioning of Components and Architectures
Kronenstrasse 19
D-70173 Stuttgart
fo +49 711 2271374 fa +49 711 2271375
http://www.avoca-vsm.com mailto:in...@avoca-vsm.com
=====================================================================
Ron Jeffries
>we set up an article on an approach we call "mutual programming" at
>http://www.avoca-vsm.com/Dateien-Download/MutualProgramming.doc .
>
>the approach seeks to combine element of the PSP and XP in away
>that keeps the developers motivated and still contains necessary
>formalism.
How do you know that additional motivation is necessary?
How do you know that additional formalism is necessary?
>
>comments are welcome.
These comments are produced during the first reading of the article, so that the
authors can benefit from its initial impact on a reader. (Written later: I find
that the article does resolve some of the "forward references" in later pages.
Subsequent readings, or reading in some other order, might make some of these
things easier to understand. If the authors expect that readers will /study/ the
article, the current order may be adequate. The paper did not lead me to expect
explanations, but to expect to find them in outside references. This could be a
failing of the reader, of course.)
HTML format would be more readily consumed. The tables and such are nice in the
DOC format, but I'm concerned that many readers may not find it accessible.
It might be better to consider all the studies, not just the ones you agree
with.
The text does not make clear to this reader whether XP1 and XP2 are the names
invented by Keefer and Lubecka, or the authors of another study.
The first table labelled Pros / Cons does not have a heading. It's not clear
what it is about. Productivity decrease is not a proven property of PP. PP
practitioners generally report the reverse. The item should be labed with a
question mark or otherwise marked speculative.
The following sentence contains a typo: "MP is a software development practice
targeted at the individual and small team level that aims to increases
productivity, quality, and reliability of software engineering work." Should be
"increase".
The description of the practices for "Green Belt" is not sufficient for this
reader to know what to do. Sufficient information from the referenced
hyperlinks should be included in the document, in my opinion, to allow the
article to stand on its own.
The "Blue Belt" description refers to "White Belt", which is not described in
the article.
What it means to be "doing QA" is not clear to this reader. It is not clear what
"2 developers, one doing actual development and the other doing QA and vice
versa" means. Do you mean there are two roles and the players switch roles from
time to time? If so, this is far less flexible than what we observe in pair
programming, where the developer and QA role may switch for a matter of moments.
Do you mean to be less flexible, or is this just a matter of emphasis?
The "blue belt" "formal" meeting needs description in this paper. I have no idea
how formal you mean the meeting to be. Black tie? I don't see why two people
working together would need to produce a "document stating the purpose, scope,
and constraints of the work product and any concerns identified". This seems
rather heavy for most work that two people could undertake, does it not?
You have the QA doing the test suite. But then you have the "vice versa" above.
It's not clear just what you are suggesting that these two people do. Are you
having them work at two separate computers, or work together? Both? Neither?
Blue Belt requires that [all?] test cases are specified before programming
begins. So what is the developer doing during this time? Also, and more
important, this process element does not allow the tester to learn from the
progress of the programming. Is that what you desire?
In "Red Belt" you are suggesting that two people working together then do Fagan
inspections on the work they did. I would think that by the time they got to
inspection they'd be quite biased. Don't such inspections work far better with
fresh eyes?
In "Red Belt" you recommend "program trace files". What is that?
In "Black Belt" you require complementary skill profiles. Why were these not
required before? What do they add at this level that isn't needed at the lower
levels?
Reference to ATA in Black Belt needs expansion in line. Paper should stand on
its own.
DLDA seems way too complex, even for someone retentive enough to do PSP and TSP.
Perhaps a diagram would help. Or maybe it really is too complex for anyone to
really do? Do the authors themselves practice DLDA?
Have the authors tried these practices themselves before perpetrating, er,
presenting them to the community? A report on their experience would be a
valuable addition to the article. This reader would expect that any real team
would get much more casual quite quickly, without much reduction in
effectiveness.
My overall impression is certainly that the process is far more formal than
anything likely to be found in the agile methods community. The authors freely
grant that the paper is speculative. I'd be interested to see a comparison of
projects done this way, and in an XP style. I would expect that the MP approach
/might/ produce better code and that it /would/ cost much more. But I could be
wrong.
Regards,
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.
Gerold Keefer
regards,
gerold
Pat Kohli
Ron Jeffries wrote:
> On Sun, 11 Aug 2002 12:58:11 +0200, Gerold Keefer <gke...@avoca-vsm.com> wrote:
>
> >we set up an article on an approach we call "mutual programming" at
> >http://www.avoca-vsm.com/Dateien-Download/MutualProgramming.doc .
> >
> >the approach seeks to combine element of the PSP and XP in away
> >that keeps the developers motivated and still contains necessary
> >formalism.
>
> How do you know that additional motivation is necessary?
Ron, as you learn about XP you will see that one of the folks associated with C3 was
a 'Coach', or maybe you forgot more about XP than anyone ever really knew, or does
it just evolve so fast that only the eXperts _really_ know what is and is not
necessary for mutual programming?
Gerold, one of the guys at the lab was interested in XP, we discussed it. Another
guy described pair program as something one does just before a total panic ensues,
or a school project is suppose to use groups.
Ron has a point about productivity; the environment might be more productive w/ two
programmers feeding it than w/ just one programmer. These things can cost a couple
of hundred bucks you know, so maybe we should hire more programmers to keep the
compilers productive, not.
Ron, I think it is great that you can help Gerold out with the syntax, English has
so little, a German can get caught napping, so the increase|increases thing was
quite notable.
Jeff Grigg
> What it means to be "doing QA" is not clear to this reader. It is not
> clear what "2 developers, one doing actual development and the other
> doing QA and vice versa" means. Do you mean there are two roles and
> less flexible [than XP pair programming], or is this just a matter of
> emphasis?
This "developer-QA" pair also struck me as confusing. I'm not sure
what it would look like. Some of my points of confusion...
6.2 - Blue Belt
Does the developer do ad-hoc testing until the automated regression
tests are written by the "QA" person?
7.3 - Automated Unit Testing
suggests that this is "Unit testing" [which is] "white box testing"
So the QA person would only write tests *AFTER* the developer wrote
the code?
Does the developer write the code and then turn it over to the QA
person to write the white box tests? And, due to the requirements of
formal software inspection, I assume that they would *NOT* run or test
the code until after both code and tests went through the inspection
process.
Or have I just misunderstood the whole thing?
_ _ _
Later in the paper...
page 16 - 8.3
If you want to direct people to a wide variety of xUnit tools...
http://www.c2.com/cgi/wiki?TestingFramework
http://www.xprogramming.com/software.htm
But, of course, there's the danger that they might learn about XP.
;->
_ _ _
on Mutual Programming:
"So far the benefits of MP are entirely hypothetical and not supported
by empirical findings."
Personally, really I like that quote. ;->
"However, close to all of the elements of MP, such as DLDA or
automated unit testing, have been shown to be beneficial when applied
in isolation."
Same could be said of XP. Further, XP's claims are also based on
experience.
Perhaps your strongest argument is that some of the practices in MP,
such as software inspections, have been "proven" effective. And
others, such as the formal tracking processes are "widely accepted by
respected institutions." (...which could be good or bad, depending on
your perspective. ;-)
_ _ _
Inspirational quote:
[17] Humphrey and Webb state:
"Although the training was generally well received, use of the PSP in
TIS started to decline as soon as the classes were completed. Soon,
none of the engineers who had been instructed in PSP techniques was
using them on the job."
Ron Jeffries
wrote:
>Ron Jeffries wrote:
>
>
>> On Sun, 11 Aug 2002 12:58:11 +0200, Gerold Keefer <gke...@avoca-vsm.com> wrote:
>>
>> >we set up an article on an approach we call "mutual programming" at
>> >http://www.avoca-vsm.com/Dateien-Download/MutualProgramming.doc .
>> >
>> >the approach seeks to combine element of the PSP and XP in away
>> >that keeps the developers motivated and still contains necessary
>> >formalism.
>>
>> How do you know that additional motivation is necessary?
>
>Ron, as you learn about XP you will see that one of the folks associated with C3 was
>a 'Coach',
I'll look that up and see what I can find out about it.
>or maybe you forgot more about XP than anyone ever really knew,
I may have forgotten something. Certainly I didn't mention everything I might
have. Was there something I could clarify here?
>or does
>it just evolve so fast that only the eXperts _really_ know what is and is not
>necessary for mutual programming?
Mutual programming is Gerold's untested new idea. He seems to think that it
offers better motivation. Since most people who learn to pair program like it
(95% is the most quoted figure), I was wondering why he felt that more
motivation was needed as part of the process. That's why I asked the question.
I'd welcome a way to motivate people who haven't tried it to do so, but his
paper doesn't seem to be about that.
>
>Gerold, one of the guys at the lab was interested in XP, we discussed it. Another
>guy described pair program as something one does just before a total panic ensues,
>or a school project is suppose to use groups.
I'm not sure what conclusion was drawn from this experience. Please tell us more
about it?
>
>Ron has a point about productivity; the environment might be more productive w/ two
>programmers feeding it than w/ just one programmer. These things can cost a couple
>of hundred bucks you know, so maybe we should hire more programmers to keep the
>compilers productive, not.
Well, Pat, I can only guess that the above was intended as humor or sarcasm. If
there was more to it than I've gleaned, I respectfully request clarification.
>Ron, I think it is great that you can help Gerold out with the syntax, English has
>so little, a German can get caught napping, so the increase|increases thing was
>quite notable.
I'm not sure what you're getting at here. Again it sounds sarcastic, but perhaps
it's just the language barrier.
Pat Kohli
Ron Jeffries wrote:
> On Mon, 12 Aug 2002 21:13:19 -0400, Pat Kohli <kohliCUT...@ameritel.net>
> wrote:
>
>
> >Ron, as you learn about XP you will see that one of the folks associated with C3 was
> >a 'Coach',
>
> I'll look that up and see what I can find out about it.
>
> >or maybe you forgot more about XP than anyone ever really knew,
>
> I may have forgotten something. Certainly I didn't mention everything I might
> have. Was there something I could clarify here?
>
No need to clarify. You described your role in C3 as a coach, and now you question the
role of motivation, and when someone tries to suggest your own role to you, you seem to
have forgotten.
"While I had no management responsibility for the project, I was the
coach and a very senior techie."
http://groups.google.com/groups?selm=9D11A1797D3A94AC.920A6CC09BAD8107.7AEEDB5689C88250%40lp.airnews.net&output=gplain
5Jan02
"Actually, Richard, if you were to spend a little more time reading the
materials, you'd find that I did almost zero programming, design, or
architecture on C3. All I did was coach them in the development
process. And the C3 team is a very standard team, with a very standard
range of people. They did it all, all by they little selves."
http://groups.google.com/groups?selm=B269594A310662B2.0D58689E3C86EFEE.5459862935503EA2%40lp.airnews.net&output=gplain
2Dec99
"Yes, just so. That's why we're writing the books, and why we think
that having a coach is important. I suspect that having a coach is key
to installation of ANY methodology, btw, not just XP."
http://groups.google.com/groups?selm=4f3t3ss1vhgkltvo3q9l1rh02sighs1t1j%404ax.com&output=gplain
26Nov99
>
> >or does
> >it just evolve so fast that only the eXperts _really_ know what is and is not
> >necessary for mutual programming?
>
> Mutual programming is Gerold's untested new idea. He seems to think that it
> offers better motivation. Since most people who learn to pair program like it
> (95% is the most quoted figure), I was wondering why he felt that more
> motivation was needed as part of the process. That's why I asked the question.
>
> I'd welcome a way to motivate people who haven't tried it to do so, but his
> paper doesn't seem to be about that.
Motivation might help. My inclination is that the buddy method is a way to show a
student how to write code. My inclination is that when I need to write code, I don't
need to tutor someone.
>
> >
> >Gerold, one of the guys at the lab was interested in XP, we discussed it. Another
> >guy described pair program as something one does just before a total panic ensues,
> >or a school project is suppose to use groups.
>
> I'm not sure what conclusion was drawn from this experience. Please tell us more
> about it?
What can I say? That is what the guy said and I agree with him. Should I ask for
permission to give his name? What details would _you_ like?
>
> >
> >Ron has a point about productivity; the environment might be more productive w/ two
> >programmers feeding it than w/ just one programmer. These things can cost a couple
> >of hundred bucks you know, so maybe we should hire more programmers to keep the
> >compilers productive, not.
>
> Well, Pat, I can only guess that the above was intended as humor or sarcasm. If
> there was more to it than I've gleaned, I respectfully request clarification.
The "not" at the end might be a useful clue to some, but, if there is any doubt, it is
good to ask. Let me fill you in on my motivation. I work for a living. I see some
awful SE get passed off as the work of professionals; I see working people like myself
who want to believe there is a simple model that will let them produce good SW quickly.
When someone comes to my home and offers to reseal my driveway for $20, I see them as
someone trying to take $20 from someone who works, trying to take it legally by offering
a quick and cheap fix. I'll talk with them and rake my leaves and talk with them and
water my flowerbeds, and talk with them until they realize that I am not only not buying,
I'd rather they don't do business in my neighborhood. When someone at my day job tries
to convince my boss that things will get easier if we forget about documenting
requirements (they are going to change anyway!), forget about those UML diagrams, and
just start coding up those tests, in pairs ... I get an attitude. Someone has just made
a good challenging job, really even harder than it needed to be, and they made it harder
for me to get good software to my customers.
>
>
> >Ron, I think it is great that you can help Gerold out with the syntax, English has
> >so little, a German can get caught napping, so the increase|increases thing was
> >quite notable.
>
> I'm not sure what you're getting at here. Again it sounds sarcastic, but perhaps
> it's just the language barrier.
I was quite sincere; I understand your English. Modern English no longer has
formal|informal address, gender in English is not an attribute of nouns which needs to be
imparted to adjectives, and in other ways, we've got little grammar, such that this
matter of the singular|plural verb could readily be overlooked by someone whose ear does
not expect a rule like 'subject verb' agreement could be violated in English. Do you
recall that old latin-based song, the conjugation illustrates just the present tense of
one Latin verb, in the singular form
Amo
Amas
Amat
Contrast that with the English equivalent
(I) love
(You) love
(He) loves
First and second person even use the same form in English. When plurals are factored in
Latin has six present tense forms of 'love' while English has two forms, 'love' and
'loves'.
Ron Jeffries
wrote:
>No need to clarify. You described your role in C3 as a coach, and now you question the
>role of motivation, and when someone tries to suggest your own role to you, you seem to
>have forgotten.
Rudeness Objection.
I was asking why /Gerold/ thinks that motivation is needed for pair programming.
It has not been my experience that it's needed among teams that actually try it.
What has been your experience with pair programming? Have you tried it enough to
get good at it? Do you need more motivation? What about pair-programming teams
you have worked with? Do you find that they lose motivation? Do you think that
Gerold's ideas would add motivation?
Uncle Bob (Robert C. Martin)
<kohliCUT...@ameritel.net> wrote:
>When someone at my day job tries
>to convince my boss that things will get easier if we forget about documenting
>requirements (they are going to change anyway!), forget about those UML diagrams, and
>just start coding up those tests, in pairs ... I get an attitude. Someone has just made
>a good challenging job, really even harder than it needed to be, and they made it harder
>for me to get good software to my customers.
Your point seems obvious. I don't blame you for your reaction. On
the other hand, it was obvious to Aristotle that heavier things must
fall faster than lighter things.
There are people out there trying XP and reporting success. You can
scoff, or you can observe, or you might even try a few experiments on
your own.
Many folks in this newsgroup have said: "I don't have to try it to
know it won't work." Frankly that attitude sounds like Bible thumping
to me. It's certainly not the attitude of a scientist or a skeptic.
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
Gerold Keefer
> This "developer-QA" pair also struck me as confusing. I'm not sure
> what it would look like.
it is quite simple: the QA part of the "duo" (to avoid the word "pair")
leads the QA activities of the duo.
he reviews the specification and implementation documents , he sets up
the test plan, and he defines the test cases. he also does the majority of
the test case execution, but he may be helped by the developer par of the
duo.
> Some of my points of confusion...
>
> 6.2 - Blue Belt
> Does the developer do ad-hoc testing until the automated regression
> tests are written by the "QA" person?
testing activities are simply not defined at the blue belt level.
the only requirement at the blue belt level is to do the defect logging.
> 7.3 - Automated Unit Testing
> suggests that this is "Unit testing" [which is] "white box testing"
> So the QA person would only write tests *AFTER* the developer wrote
> the code?
"The test cases of the unit test suite have to be specified before the
implementation of the executable work product begins."
> Does the developer write the code and then turn it over to the QA
> person to write the white box tests?
yes.
> And, due to the requirements of
> formal software inspection, I assume that they would *NOT* run or test
> the code until after both code and tests went through the inspection
> process.
running the code is not prohibited at any time. testing should be done
after the reviews.
> Later in the paper...
>
> page 16 - 8.3
> If you want to direct people to a wide variety of xUnit tools...
> http://www.c2.com/cgi/wiki?TestingFramework
> http://www.xprogramming.com/software.htm
>
> But, of course, there's the danger that they might learn about XP.
exactly.
> ;->
> _ _ _
>
> on Mutual Programming:
> "So far the benefits of MP are entirely hypothetical and not supported
> by empirical findings."
>
> Personally, really I like that quote. ;->
personally, i like integrity.
> "However, close to all of the elements of MP, such as DLDA or
> automated unit testing, have been shown to be beneficial when applied
> in isolation."
>
> Same could be said of XP.
please decide on this after you had a look at
http://www.ipd.uka.de/~muellerm/publications/edser02.pdf
http://www.escom.co.uk/conference2001/papers/nawrocki.pdf
http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html
> Further, XP's claims are also based on
> experience.
mainly the experience of the consulting companies thoughtworks and
objectmentor that are by strange coincidence marketing XP.
> Perhaps your strongest argument is that some of the practices in MP,
> such as software inspections, have been "proven" effective.
my strongest argument is that the developers can *measure* the
effect of the practices. if the practices don't work they are entiteled to
throw them away. but the data has to be put on the table, something
you won't find in hundreds of pages XP literature.
> Inspirational quote:
>
> [17] Humphrey and Webb state:
> "Although the training was generally well received, use of the PSP in
> TIS started to decline as soon as the classes were completed. Soon,
> none of the engineers who had been instructed in PSP techniques was
> using them on the job."
exactly this is what we are trying to fix.
regards,
gerold
Gerold Keefer
> > Further, XP's claims are also based on
> > experience.
>
> mainly the experience of the consulting companies thoughtworks and
> objectmentor that are by strange coincidence marketing XP.
i actually came across an indication on how business ehtics are
implemented in those circles:
http://www.bsa.org/usa/press/newsreleases/2001-01-31.439.phtml
regards,
gerold
Carl Thronson
> hi *,
>
> we set up an article on an approach we call "mutual programming" at
> http://www.avoca-vsm.com/Dateien-Download/MutualProgramming.doc .
>
> the approach seeks to combine element of the PSP and XP in away
> that keeps the developers motivated and still contains necessary
> formalism.
>
> comments are welcome.
>
> best regards,
>
> gerold
Suppose you have two kids, ages 6 and 10. You can:
watch them yourself.
hire a nanny.
hire your 16 year old niece.
let the 10 year old watch the 6 year old.
let them do whatever they want.
Peer programming would be like letting two 8 years olds watch each
other.
Look, if you want to get better quality work out of programmers, take
a closer look at what they're doing. It's that simple.
random testing
more detailed specifications
Your document looks interesting; but, considering how you are making
this harder than it has to be, I think you're just fishing for a
subject to write a paper about. You're like a scientist that can't
figure out what to study.
-Carl
I just decided my role model is Jimmy Carter. When you've been
president what's left for you to do; but, to pick up a hammer and
start building houses?
David Wolff
Carl Thronson <carlth...@yahoo.com> wrote:
>Gerold Keefer <gke...@avoca-vsm.com> wrote in message
>news:<3D564343...@avoca-vsm.com>...
>> hi *,
>>
>> we set up an article on an approach we call "mutual programming" at
>> http://www.avoca-vsm.com/Dateien-Download/MutualProgramming.doc .
>>
>> the approach seeks to combine element of the PSP and XP in away
>> that keeps the developers motivated and still contains necessary
>> formalism.
>>
>> comments are welcome.
>>
>> best regards,
>>
>> gerold
>
>Suppose you have two kids, ages 6 and 10. You can:
>
>watch them yourself.
>hire a nanny.
>hire your 16 year old niece.
>let the 10 year old watch the 6 year old.
>let them do whatever they want.
>
>Peer programming would be like letting two 8 years olds watch each
>other.
If your fellow programmers are 8-year-olds, then you have a problem that
no methodology can fix.
If your fellow programmers are reasonably intelligent and
well-intentioned adults, they can often assist each other.
Sounds like a profound lack of trust to me.
Thanks --
David
(remove "xx" to reply)
Otis Bricker
@avoca-vsm.com:
A low and uncalled for insult. If you BOTHERED to read the article you
posted. you would have seen this quote,"ThoughtWorks promptly responded
once the situation was brought to management’s attention," said Bob Kruger,
vice president of enforcement for the BSA. HE goes on to say that it is not
uncommon for this sort of situation to happen to businesses that do not
devote resources specifically to tracking software liceneses. Sure sounds
like a technical not an ethical slip. I KNOW that every piece of software
on my computer has a valid license. I am not sure I could PROVE it if
someone came in and demanded that I do. One of those cases where we are
guilty until proven innocent.
But you have always seemed to have a personal grudge against these guys so
I shouldn't be surpised.
I was surprised to see that AVOCA seems to be offering XP training. Or at
least an overview of Agile Methods. My German was never more that beginner
level and that was 25 years ago. So I might be misunderstanding your
training page.
Otis
Dmitriy Lapshin
> If your fellow programmers are reasonably intelligent and
> well-intentioned adults, they can often assist each other.
That's when courage is valuable, IMO. As Kent Beck says
in his "Extreme Programming Explained", the team accepts
responsibility voluntarily, if I have translated it back to
English right from my Russian edition :-)
--
Dmitriy Lapshin
X-Unity Unit Testing and Integration Environment
http://x-unity.miik.com.ua
Gerold Keefer
> A low and uncalled for insult. If you BOTHERED to read the article you
> posted. you would have seen this quote,"ThoughtWorks promptly responded
> once the situation was brought to management’s attention," said Bob Kruger,
> vice president of enforcement for the BSA. HE goes on to say that it is not
> uncommon for this sort of situation to happen to businesses that do not
> devote resources specifically to tracking software liceneses. Sure sounds
> like a technical not an ethical slip. I KNOW that every piece of software
> on my computer has a valid license. I am not sure I could PROVE it if
> someone came in and demanded that I do. One of those cases where we are
> guilty until proven innocent.
actually, the report dates back a while and there are chances
that they improved at thoughtworks. on the other hand, if you
are in the software consulting business you kind of know what
licenses are here for. and you are not voluntarily paying half a
million dollars for a "technical slip".
> But you have always seemed to have a personal grudge against these guys so
> I shouldn't be surpised.
i have a personal grudge against snake oil selling people simply
for the reason that they made my job harder in the past.
i have repeatedly uncovered major "inconsistencies" in the reports
of the XP experts (remember the level 5 in 4 months thing?) and
i am continuing to do so as long as they are there.
i encourage everybody to uncover inconsistencies in our reports as well.
> I was surprised to see that AVOCA seems to be offering XP training.
we are not doing that.
you can find information about the topic and the reasons in the second
last paragraph of page 3 of a paper we published half a year ago at
http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf .
it is nice to have proper documentation.
regards,
gerold
Gerold Keefer
> Peer programming would be like letting two 8 years olds watch each
> other.
i was actually not writing about peer programming, but about
mutual programming. you seem to have troubles with reading
the "detailed specification" that you further down demand.
> Look, if you want to get better quality work out of programmers, take
> a closer look at what they're doing. It's that simple.
>
> random testing
may i question if you are older than 8?
if you would have had the chance to learn about software -i am
even not talking about programming- at a most trivial level, you
would not recommend random testing.
> more detailed specifications
>
> Your document looks interesting; but, considering how you are making
> this harder than it has to be, I think you're just fishing for a
> subject to write a paper about. You're like a scientist that can't
> figure out what to study.
this is your opinion that i respect, although not to a high degree.
my opinion is that in most situations mutual programming is
a simpification.
> -Carl
regards,
gerold
David B Lightstone
"Otis Bricker" <obri...@my-dejanews.com> wrote in message
news:Xns926BDB47415B9ob...@204.127.68.17...
> Gerold Keefer <gke...@avoca-vsm.com> wrote in news:3D5BA817.A103C691
> @avoca-vsm.com:
>
> > Gerold Keefer wrote:
> >
> >> > Further, XP's claims are also based on
> >> > experience.
> >>
> >> mainly the experience of the consulting companies thoughtworks and
> >> objectmentor that are by strange coincidence marketing XP.
> >
> > i actually came across an indication on how business ehtics are
> > implemented in those circles:
> > http://www.bsa.org/usa/press/newsreleases/2001-01-31.439.phtml
> >
> > regards,
> >
> > gerold
> >
>
> A low and uncalled for insult. If you BOTHERED to read the article you
> posted. you would have seen this quote,"ThoughtWorks promptly responded
> once the situation was brought to management's attention," said Bob Kruger,
> vice president of enforcement for the BSA.
Mr Kruger is providing plausible denyability. Somebody blew the whistle. That in
itself tells you everything you need to know. The internal infrastructure failed
to address the matter promptly. Internally a Hacker/Cowboy mentality must be
operating. It was expedient to copy so they did rather than go thru the
logistics of purchasing.
Whether the Hacker/Cowboy mentality reflects upon other issues (such as software
QA, Mr Keefer's primary interest) is a separate issue. The old expression - "a
fish rots from its head" - is probably applicable
> HE goes on to say that it is not
> uncommon for this sort of situation to happen to businesses that do not
> devote resources specifically to tracking software liceneses. Sure sounds
> like a technical not an ethical slip. I KNOW that every piece of software
> on my computer has a valid license. I am not sure I could PROVE it if
> someone came in and demanded that I do. One of those cases where we are
> guilty until proven innocent.
I suspect that you could. You have the actual (not forged) distribution disks
don't you? They have liscense numbers don't they? It may be time consuming, but
you could go to each computer and make a list of the serial numbers for each
software package. There are only two possibilities, there will be duplicates or
there won't
Yes, I am aware that site liscensed software doesn't have serial numbers. In
which case you have the disk.
The only open question is whether the disk had been forged.
>
> But you have always seemed to have a personal grudge against these guys so
> I shouldn't be surpised.
When did demanding ethical conduct become a grudge?
Jeff Grigg
> > Some of my points of confusion...
> >
> > 6.2 - Blue Belt
> > Does the developer do ad-hoc testing until the automated regression
> > tests are written by the "QA" person?
Gerold Keefer <gke...@avoca-vsm.com> wrote...
> testing activities are simply not defined at the blue belt level.
> the only requirement at the blue belt level is to do the defect logging.
?
Are you talking about the "Green Belt" level?
4.1, page 8:
Table shows that Blue Belt introduces two practices: "Work Product
Previews" and "Automated Unit Testing/Inspections"
6.2 Blue Belt, page 10:
under "Required Elements"
"In the case of an executable work product this is an automated unit
test suite implemented by the QA responsible."
"The test cases of the unit test suite have to be specified before the
implementation of the executable work product begins."
_ _ _
> Jeff Grigg wrote:
> > 7.3 - Automated Unit Testing
> > suggests that this is "Unit testing" [which is] "white box testing"
> > [...]
Gerold Keefer <gke...@avoca-vsm.com> wrote...
> "The test cases of the unit test suite have to be specified before the
> implementation of the executable work product begins."
Oops! Sorry, I missed that point in my first reading.
I would probably call these "black box" tests, as they're written
without knowledge of the internal implementation of the objects one is
testing.
_ _ _
> Jeff Grigg wrote:
> > [...], XP's claims are also based on experience.
Gerold Keefer <gke...@avoca-vsm.com> wrote...
> mainly the experience of the consulting companies thoughtworks and
> objectmentor that are by strange coincidence marketing XP.
XP was promoted based on experience of successful projects long before
the consulting companies got involved.
Gerold Keefer
> Gerold Keefer <gke...@avoca-vsm.com> wrote...
> > testing activities are simply not defined at the blue belt level.
> > the only requirement at the blue belt level is to do the defect logging.
>
> ?
> Are you talking about the "Green Belt" level?
yes, green. i'll add that to my defect log.
> I would probably call these "black box" tests, as they're written
> without knowledge of the internal implementation of the objects one is
> testing.
this must not be the case. you could for example have the
design ready. knowing about design is not exactly black box.
> XP was promoted based on experience of successful projects long before
> the consulting companies got involved.
which successful project(s)? are we talking C3?
you may want to have a look at the facts i collected in my
paper and then decide if C3 was a success.
i have no information on when exactly the named consulting
companies started to promote. facts are that the vast majority
of the C3 team members ended up in either of them.
regards,
gerold
Martin Fowler
>Jeff Grigg wrote:
>
>>[...], XP's claims are also based on experience.
>>
>
> Gerold Keefer <gke...@avoca-vsm.com> wrote...
>
>>mainly the experience of the consulting companies thoughtworks and
>>objectmentor that are by strange coincidence marketing XP.
>
>
> facts are that the vast majority
>of the C3 team members ended up in either of them.
From the C3 team Ron Jeffries works closely with ObjectMentor. Kent
Beck and I worked with them on immersion courses. Chet Hendrickson
joined ThoughtWorks for a while and since went independent. I work for
ThoughtWorks.
So counting all those I make that 4 people from C3 who have worked with
ObjectMentor or ThoughtWorks.
During the first year there were 16 members of the C3 team, more joined
later on when I wasn't directly involved. Of that group at least five
that I know of are currently employees of DaimlerChrysler (I'm not sure
where everybody is now.)
Martin
Carl Thronson
Exactly right. I'm glad you agree with me.
-Carl
Carl Thronson
> > random testing
>
> you
> would not recommend random testing.
>
Why not?
-Carl
Gerold Keefer
> Why not?
>
> -Carl
stefan answered that, some time ago. i would also
note that random testing is something different from
statistical testing.
> If you had all the time of the world, random testing would find
probably 30%
> of all the bugs in a program. If you performed well designed testing
with
> coverage analysis, automation, etc, then you would certainly find more
than
> 50% of them in a reasonable timeframe.
> The number don't really matter. Random testing may seem interesting
at
> first because it's low on intellectual effort, but random testing is
child's
> play and to get serious results you must grow up.
> Everyone can drive a car but not everyone can participate in a formula
1
> race.
> Regards, Stefan Steurs.
Gerold Keefer
> From the C3 team Ron Jeffries works closely with ObjectMentor. Kent
> Beck and I worked with them on immersion courses. Chet Hendrickson
> joined ThoughtWorks for a while and since went independent. I work for
> ThoughtWorks.
>
> So counting all those I make that 4 people from C3 who have worked with
> ObjectMentor or ThoughtWorks.
>
> During the first year there were 16 members of the C3 team, more joined
> later on when I wasn't directly involved. Of that group at least five
> that I know of are currently employees of DaimlerChrysler (I'm not sure
> where everybody is now.)
>
> Martin
you kind of forgot about Ann Anderson, who was on the program
committee XP2001 and published "Extreme Programming Installed"
together with ron.
anyway, "vast majority" is wrong. i agree. on the other hand you would
not see a quarter of the staff of a failed project publishing books and
papers about it too often.
regards,
gerold
Ron Jeffries
>you kind of forgot about Ann Anderson, who was on the program
>committee XP2001 and published "Extreme Programming Installed"
>together with ron.
>
>anyway, "vast majority" is wrong. i agree. on the other hand you would
>not see a quarter of the staff of a failed project publishing books and
>papers about it too often.
The project shipped and went into use. XP is still being used at
DaimlerChrysler, to good effect. Maybe it wasn't a failed project after all?
Martin Fowler
> you kind of forgot about Ann Anderson, who was on the program
> committee XP2001 and published "Extreme Programming Installed"
> together with ron.
True, but she did not end up at either Object Mentor or ThoughtWorks.
Hence I didn't think it was relevant to my point.
Martin
Carl Thronson
I suspect the underlying principles in Stefan's argument are:
1. You will lose effectiveness when you unwittingly perform 2 tests
that appear to test different things; but, actually test the same
thing. I suppose you've probably got some name for that, or perhaps
someone's written a graduate thesis on the concept; but, any engineer
who doesn't have his head on backwards should know it.
2. Test automation is a good thing. Again, I think this is just
common sense. It means you require less resources to execute tests.
And it means you execute the same tests each time, so you can really
get a good handle on the trend. You can tell if the software is
improving or not because you're performing the same tests each time.
Unfortunately, I don't think this concept is quite as well understood;
otherwise, the company I used to work for, Silicon Valley Networks,
would less likely have gone out of business. They made a test
management system. Do you know what that is?
Are there any other underlying truths in what Stefan is saying? If
there are, I would like to know. Unless of course they're just
obvious things. Well, actually even if they're just obvious things, I
would still like to know if you would call attention to these things.
Anyway, I'm talking about performing tests at random times. Sorry for
the confusion. Try walking into the cubes of one your engineers
unannounced and look at their code. How well does the code conform to
best practices? That's what I mean by random testing.
-Carl
Andrew Gabb
> Your point seems obvious. I don't blame you for your reaction. On
> the other hand, it was obvious to Aristotle that heavier things must
> fall faster than lighter things.
It's generally obvious to me too. Something to do with friction and
terminal velocities.
Try the brick/feather test some time. :=)
Andrew
--
[Canberra 19-23 Aug Ph:02 626-55941(temp), AH:02 6297-5531]
Andrew Gabb
email: ag...@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----
Ron Jeffries
>"Uncle Bob (Robert C. Martin)" wrote:
>> Your point seems obvious. I don't blame you for your reaction. On
>> the other hand, it was obvious to Aristotle that heavier things must
>> fall faster than lighter things.
>
>It's generally obvious to me too. Something to do with friction and
>terminal velocities.
>
>Try the brick/feather test some time. :=)
We did that one back in high school. In a vacuum.
Pat Kohli
Ron Jeffries wrote:
> On Tue, 13 Aug 2002 23:48:02 -0400, Pat Kohli <kohliCUT...@ameritel.net>
> wrote:
>
> >No need to clarify. You described your role in C3 as a coach, and now you question the
> >role of motivation, and when someone tries to suggest your own role to you, you seem to
> >have forgotten.
>
> Rudeness Objection.
>
> I was asking why /Gerold/ thinks that motivation is needed for pair programming.
> It has not been my experience that it's needed among teams that actually try it.
>
What does call for motivation, then? PP looked like a drop dead objection even to
programmers who would not miss requirements documentation when it ended.
>
> What has been your experience with pair programming?
It was exactly the same as jumping off the water tower w/o a bungee cord - a thought
experiment.
> Have you tried it enough to
> get good at it?
Ron, Ron, Ron, pair programming is not something I can get good at, just by me by trying
it. It is done in pairs and some pairs are just going to be more productive than others and
then we switch. Would you care to try another trick question on me?
> Do you need more motivation?
Not at all. My reluctance to crash off the water tower also has nothing to do w/ lack of
motivation.
> What about pair-programming teams
> you have worked with?
When you use the term 'pair programming teams', do you refer to a specific pair, or a job
that uses pair programming?
> Do you find that they lose motivation?
I don't think it is about motivation. My best guess is that Gerold is trying to accommodate
some of the aspects of XP that he considers to be the least destructive. I still think that
pair programming is inefficient, even if it is not destructive. Be that as it may, my best
guess also sees you seeing the same thing in Gerold's current course of action, and you find
it threatening so you respond with lame criticism.
> Do you think that
> Gerold's ideas would add motivation?
>
My hunch is that in the heat of battle developers forget their PSP stuff. My suspicion is
that if the developers were held accountable by other developers, maybe they would stick to
their PSP. My guess is that when skill levels are improving, it may be possible to go to
pair programming w/o blowing costs sky high, and schedule out of the water.
The facts that Gerold references early in the paper do substantiate the underlying mistrust
I have for pair programming. Pair programming is inefficient.
J. Nawrocki, A. Wojciechowski, Experimental Evaluation of Pair Programming, ESCOM 2001
Paper.
F. Padberg, M. M. Müller, Extreme Programming from an Engineering Economics Viewpoints,
EDSER Workshop, May 2002.
Pat Kohli
"Uncle Bob (Robert C. Martin)" wrote:
> On Tue, 13 Aug 2002 23:48:02 -0400, Pat Kohli
> <kohliCUT...@ameritel.net> wrote:
>
> >When someone at my day job tries
> >to convince my boss that things will get easier if we forget about documenting
> >requirements (they are going to change anyway!), forget about those UML diagrams, and
> >just start coding up those tests, in pairs ... I get an attitude. Someone has just made
> >a good challenging job, really even harder than it needed to be, and they made it harder
> >for me to get good software to my customers.
>
> Your point seems obvious. I don't blame you for your reaction. On
> the other hand, it was obvious to Aristotle that heavier things must
> fall faster than lighter things.
>
Now we have vacuum tanks and experiments. eXperiments show that pair programming reduces
efficency. Please act surprised for me.
>
> There are people out there trying XP and reporting success. You can
> scoff, or you can observe, or you might even try a few experiments on
> your own.
>
Some folks say the C3 project was a success and others suggest that the early success on the
first release of C3 may have been due to the first customer, that when the goal donor second
customer did not see eye-to-eye with the gold owner, the project got tanked.
>
> Many folks in this newsgroup have said: "I don't have to try it to
> know it won't work." Frankly that attitude sounds like Bible thumping
> to me. It's certainly not the attitude of a scientist or a skeptic.
>
Have fun learning dozens of assembly languages.
>
> 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 |
- Pat
ko...@ameritel.net
Phlip
> Now we have vacuum tanks and
> experiments. eXperiments show that pair programming reduces
> efficency. Please act surprised for me.
Our experiments showed it increased productivity.
However, They Are Just Rules.
We should hope that overpaid engineers with extensive training and
experience could just possibly be expected to identify for themselves which
rules are working for their team on their project. Maybe.
(For some reason, however, we can't get the original poster of this thread
to follow this simple advice.)
--
Phlip
http://www.greencheese.org/EvolutionaryPsychology
-- Shock Value Added --
Phlip
Pat Kohli wrote:
> Some folks say the C3 project was a success and others suggest that the
> early success on the
> first release of C3 may have been due to the first customer, that when the
> goal donor second
> customer did not see eye-to-eye with the gold owner, the project got
> tanked.
C3 was Chryslers attempt to learn OO programming. To do this, they threw
their hardest problem at hired guns. Don't do that; start with a small, but
not trivial, project.
The end-users of the C3 source had no motivation to switch to it; they
weren't the same group as the ones who hired the guns. Don't do that.
C3 failed because it was prevented from trying the "frequent releases" rule
to see if it would work. The team created perfectly good releases which the
customers installed very infrequently. Don't do that, even if you are not
using XP.
>> Many folks in this newsgroup have said: "I don't have to try it to
>> know it won't work." Frankly that attitude sounds like Bible thumping
>> to me. It's certainly not the attitude of a scientist or a skeptic.
>
> Have fun learning dozens of assembly languages.
This is a matter of orders of magnitude. The productivity boost using a
very high level language is around 100 to 1.
If I thought of a technique that could give a productivity boost of from
0.5 to 5 times, which was easy for you to try, which was easy for you to
measure, which never yielded a false positive, which showed failure very
simply and cleanly, then it would be remiss of me not to recommend you try
it.
And it would be remiss of you not to try it. If you were a CMM Level 5
company and you did not at least attempt an XP-style project (or any other
known style) you would risk losing your certification for "not
experimenting with your process to improve it."
--
Phlip
http://www.c2.com/cgi/wiki?PhlIp
-- Will the bailiff please remove the juror who started the wave --
David B Lightstone
"Phlip" <phli...@yahoo.com> wrote in message
news:Q3G79.3960$vM.139...@newssvr15.news.prodigy.com...
> Pat Kohli wrote:
>
> > Now we have vacuum tanks and
> > experiments. eXperiments show that pair programming reduces
> > efficency. Please act surprised for me.
>
> Our experiments showed it increased productivity.
Great! Where have you choosen to publish the results?
or is that Proprietary information?
David B Lightstone
> [Follow-ups set to the XP newsgroup]
>
>
> And it would be remiss of you not to try it. If you were a CMM Level 5
> company and you did not at least attempt an XP-style project (or any
other
> known style) you would risk losing your certification for "not
> experimenting with your process to improve it."
>
Lets see if I understand your argument. It seems to mean - If you are
manufacturing firm, using NC machines in a flexible machining environment,
you should go out an buy an old manually operated machine and attempt to
use it in an effort to improve your process
Is that what you are trying to tell the world with your little gem of
rhetoric?
How about trying to hack out a project every once and a while? Would that
not also prevent them from losing their certification?
Gerold Keefer
> We should hope that overpaid engineers with extensive training and
> experience could just possibly be expected to identify for themselves which
> rules are working for their team on their project. Maybe.
>
> (For some reason, however, we can't get the original poster of this thread
> to follow this simple advice.)
right, because although your advice may be simple it is stupid as
well. in many cases it is not up to the engineer to decide on the
terms of trade. the mainstream and other external factors
play a big role in those decisions. wisdom the market share
of wintel.
i encourage everybody curious to try out XP or pair programming.
there is nothing wrong with this.
my role was to work on the integrity of the assumptions that may
influence the decision.
> --
> Phlip
> http://www.greencheese.org/EvolutionaryPsychology
> -- Shock Value Added --
regards,
gerold
Gerold Keefer
> I suspect the underlying principles in Stefan's argument are:
>
> 1. You will lose effectiveness when you unwittingly perform 2 tests
> that appear to test different things; but, actually test the same
> thing. I suppose you've probably got some name for that, or perhaps
> someone's written a graduate thesis on the concept; but, any engineer
> who doesn't have his head on backwards should know it.
ok.
> 2. Test automation is a good thing. Again, I think this is just
> common sense. It means you require less resources to execute tests.
wrong. automation might cause more effort than manual testing,
particularly when you do it wrong. brian marick wrote a paper about that.
you frequently see negative ROI figures with test automation.
> And it means you execute the same tests each time, so you can really
> get a good handle on the trend. You can tell if the software is
> improving or not because you're performing the same tests each time.
learn the trade. if you are performing the *same* tests all the time
you are only checking that what used to work, still works.
if you change your software this is of very limited use to have a trend.
> Unfortunately, I don't think this concept is quite as well understood;
> otherwise, the company I used to work for, Silicon Valley Networks,
> would less likely have gone out of business. They made a test
> management system. Do you know what that is?
kinf of.
> Are there any other underlying truths in what Stefan is saying? If
> there are, I would like to know. Unless of course they're just
> obvious things. Well, actually even if they're just obvious things, I
> would still like to know if you would call attention to these things.
if i do that, are you paying me by the hour?
> Anyway, I'm talking about performing tests at random times. Sorry for
> the confusion. Try walking into the cubes of one your engineers
> unannounced and look at their code. How well does the code conform to
> best practices? That's what I mean by random testing.
sounds slightly random to me, honetly. the concept of random testing is
often used as a synonym for poking around. serious random testing
starts as you really have statistical distributions defined with your tests.
for example the musa method/SRE.
> -Carl
regards,
gerold
Ron Jeffries
wrote:
>> Have you tried it enough to
>> get good at it?
>
>Ron, Ron, Ron, pair programming is not something I can get good at, just by me by trying
>it. It is done in pairs and some pairs are just going to be more productive than others and
>then we switch. Would you care to try another trick question on me?
Yes. Have you tried it with enough people to know that?
Ron Jeffries
>C3 failed because it was prevented from trying the "frequent releases" rule
>to see if it would work. The team created perfectly good releases which the
>customers installed very infrequently. Don't do that, even if you are not
>using XP.
Not quite true. We released to production typically monthly. However we never
figured out how to release a partial payroll program in a way that would satisfy
the payroll people (and the developers) that it made sense.
Subsequently we thought of a way that might have worked. At the time, the
inability to release the new populations piecmeal (either a few people at a time
or a few payroll functions at a time) was not there.
That one wasn't business's fault.
Ron Jeffries
>[Follow-ups set to the XP newsgroup]
>
>Pat Kohli wrote:
Phlip: these people aren't listening. Let's govern ourselves accordingly.
Phlip
> Phlip wrote:
>
> >[Follow-ups set to the XP newsgroup]
> >
> >Pat Kohli wrote:
>
> Phlip: these people aren't listening. Let's govern ourselves accordingly.
Clamping down on the cross-posting has worked before ;-)
--
Phlip
Carl Thronson
> Carl Thronson wrote:
>
> > I suspect the underlying principles in Stefan's argument are:
> >
> > 1. You will lose effectiveness when you unwittingly perform 2 tests
> > that appear to test different things; but, actually test the same
> > thing. I suppose you've probably got some name for that, or perhaps
> > someone's written a graduate thesis on the concept; but, any engineer
> > who doesn't have his head on backwards should know it.
>
> ok.
>
> > 2. Test automation is a good thing. Again, I think this is just
> > common sense. It means you require less resources to execute tests.
>
> wrong. automation might cause more effort than manual testing,
> particularly when you do it wrong. brian marick wrote a paper about that.
> you frequently see negative ROI figures with test automation.
>
Hmmm... I am really blown away by this. I have always believed
automating a task is better than doing it by hand. The number of
products on the market for automating tests suggests there must be
some truth in it. I'm also seeing a trend these days, where companies
just can't keep up with testing they need to do and so they are
shipping the work to other countries. Who is Brian Marick? Where can
I get his paper?
> > And it means you execute the same tests each time, so you can really
> > get a good handle on the trend. You can tell if the software is
> > improving or not because you're performing the same tests each time.
>
> learn the trade. if you are performing the *same* tests all the time
> you are only checking that what used to work, still works.
> if you change your software this is of very limited use to have a trend.
>
I disagree. I think it's very important to make sure what used to
work still works.
> > Unfortunately, I don't think this concept is quite as well understood;
> > otherwise, the company I used to work for, Silicon Valley Networks,
> > would less likely have gone out of business. They made a test
> > management system. Do you know what that is?
>
> kinf of.
>
I don't know if there is a formal definition anywhere, so your
intuition is probably good enough. Basicly, if you know what a test
is, a test management system abstracts that notion and gives you the
capability to "manage" them. Managing means plan, define, edit, run
or schedule to run, collect results from, generate reports from the
results, view trends, things like that...
> > Are there any other underlying truths in what Stefan is saying? If
> > there are, I would like to know. Unless of course they're just
> > obvious things. Well, actually even if they're just obvious things, I
> > would still like to know if you would call attention to these things.
>
> if i do that, are you paying me by the hour?
>
Hmm... You want me to pay you to tell me something; but, I don't know
what that something is going to be and I don't have any idea if it
will be useful or not. I think I will pass.
> > Anyway, I'm talking about performing tests at random times. Sorry for
> > the confusion. Try walking into the cubes of one your engineers
> > unannounced and look at their code. How well does the code conform to
> > best practices? That's what I mean by random testing.
>
> sounds slightly random to me, honetly. the concept of random testing is
> often used as a synonym for poking around. serious random testing
> starts as you really have statistical distributions defined with your tests.
> for example the musa method/SRE.
>
> > -Carl
>
> regards,
>
> gerold
So, I shouldn't have used the term "random testing." Excuse me.
Anyway, now I think you should know what I mean.
Let me give you an analogy in case it helps.
Suppose you own a construction company. Suppose you hired the
cheapest day laborers you can find. They don't have licenses or
references.
I think there's only 2 things that matter.
Do they know what they're doing? Watch them for a while and you will
find out.
Will they take short cuts when you're not looking? Surprise
inspections should fix that.
-Carl
David B Lightstone
"Carl Thronson" <carlth...@yahoo.com> wrote in message
news:3c72d700.02081...@posting.google.com...
> Gerold Keefer <gke...@avoca-vsm.com> wrote in message
news:<3D5FC337...@avoca-vsm.com>...
> > Carl Thronson wrote:
> >
> >
> > > 2. Test automation is a good thing. Again, I think this is just
> > > common sense. It means you require less resources to execute tests.
> >
> > wrong. automation might cause more effort than manual testing,
> > particularly when you do it wrong. brian marick wrote a paper about
that.
> > you frequently see negative ROI figures with test automation.
> >
>
> Hmmm... I am really blown away by this. I have always believed
> automating a task is better than doing it by hand. The number of
> products on the market for automating tests suggests there must be
> some truth in it. I'm also seeing a trend these days, where companies
> just can't keep up with testing they need to do and so they are
> shipping the work to other countries. Who is Brian Marick? Where can
> I get his paper?
His web site is
http://www.testing.com/
>
> > > And it means you execute the same tests each time, so you can really
> > > get a good handle on the trend. You can tell if the software is
> > > improving or not because you're performing the same tests each time.
> >
> > learn the trade. if you are performing the *same* tests all the time
> > you are only checking that what used to work, still works.
> > if you change your software this is of very limited use to have a
trend.
> >
>
> > > Anyway, I'm talking about performing tests at random times. Sorry
for
> > > the confusion. Try walking into the cubes of one your engineers
> > > unannounced and look at their code. How well does the code conform
to
> > > best practices? That's what I mean by random testing.
Oh the old "snap inspection" of the troops.
I'm not sure what is being measured. Progress, whether the troops have idle
time.
Keith Ray
carlth...@yahoo.com (Carl Thronson) wrote:
> > wrong. automation might cause more effort than manual testing,
> > particularly when you do it wrong. brian marick wrote a paper about that.
> > you frequently see negative ROI figures with test automation.
> >
>
> Hmmm... I am really blown away by this. I have always believed
> automating a task is better than doing it by hand. The number of
> products on the market for automating tests suggests there must be
> some truth in it. I'm also seeing a trend these days, where companies
> just can't keep up with testing they need to do and so they are
> shipping the work to other countries. Who is Brian Marick? Where can
> I get his paper?
Brian's paper harkens back to "traditional" style testing, where all the
testing is at the end of the project. In that situation, the software
isn't evolving, and you don't need to test something more than a few
times.
In XP projects, testing starts at the beginning of the project, and must
re-verify in each iteration that features implemented earlier are still
working. This makes automating testing very profitable, because
otherwise the testers would not be able to keep up with the developers.
--
C. Keith Ray
Phlip
Keith Ray wrote:
> Brian's paper harkens back to "traditional" style testing, where all the
> testing is at the end of the project. In that situation, the software
> isn't evolving, and you don't need to test something more than a few
> times.
>
> In XP projects, testing starts at the beginning of the project, and must
> re-verify in each iteration that features implemented earlier are still
> working. This makes automating testing very profitable, because
> otherwise the testers would not be able to keep up with the developers.
As one of the authors of the Agile Manifesto, Brian's site contains a
sweet list of test-first resources:
http://www.testing.com/agile/index.html
Quality is cheaper, folks!
--
Phlip
http://www.greencheese.org/AndNowaNitelyLitelyUrbanOne
-- Friends don't let friends use Closed Source software --
Keith Ray
Phlip <phli...@yahoo.com> wrote:
> As one of the authors of the Agile Manifesto, Brian's site contains a
> sweet list of test-first resources:
>
> http://www.testing.com/agile/index.html
>
> Quality is cheaper, folks!
I'm adding that URL to my minifaq.
Uncle Bob (Robert C. Martin)
wrote:
>"Uncle Bob (Robert C. Martin)" wrote:
>> Your point seems obvious. I don't blame you for your reaction. On
>> the other hand, it was obvious to Aristotle that heavier things must
>> fall faster than lighter things.
>
>It's generally obvious to me too. Something to do with friction and
>terminal velocities.
>
>Try the brick/feather test some time. :=)
Actually, Aristotle's notion was not simply that heavy things fall
faster than lighter things, but that objects fall at a rate that is
proportional to their weight. So a two pound object falls *twice* as
fast as a one pound object. This violates almost any observation you
can make. But the notion was considered *TRUTH* for two thousand
years.
People do not lightly give up their beliefs.
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
Uncle Bob (Robert C. Martin)
<kohliCUT...@ameritel.net> wrote:
>Now we have vacuum tanks and experiments. eXperiments show that pair programming reduces
>efficency. Please act surprised for me.
Some research indicates that PP is less efficient, other research
indicates it is more efficient. There is slighly more research with
the latter outcome than the former.
I *like* pair programming. I do it whenever I can. I find it helps
me think more clearly, and the code I produce with my partners is
better than the code I produce alone. YMMV.
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
Uncle Bob (Robert C. Martin)
<kohliCUT...@ameritel.net> wrote:
>Some folks say the C3 project was a success and others suggest that the early success on the
>first release of C3 may have been due to the first customer, that when the goal donor second
>customer did not see eye-to-eye with the gold owner, the project got tanked.
The C3 project was cancelled. It's hard to view cancellation as a
success. The cancellation came about because someone on the business
side did some sums. The sums indicated that the project was not
profitable. Other people had done those sums at other times and come
to different conclusions. That's business, and that's life.
The more interesting question about C3 is whether the developers were
making consistent and significant progress towards the goal. To that
the answer appears to be affirmative.
However, C3 is old hat. There are a plethora of other XP project out
there, so there's plenty of new observations to make.
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
Uncle Bob (Robert C. Martin)
<kohliCUT...@ameritel.net> wrote:
>>
>> Many folks in this newsgroup have said: "I don't have to try it to
>> know it won't work." Frankly that attitude sounds like Bible thumping
>> to me. It's certainly not the attitude of a scientist or a skeptic.
>>
>
>Have fun learning dozens of assembly languages.
>
Lets see... I know BAL/360, PDP8, PDP11, 8080, 8086, M365,
Varian/620, 6502, perhaps a few more. It *is* fun. Not only is it
fun, but it can be very useful.
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
Uncle Bob (Robert C. Martin)
<kohliCUT...@ameritel.net> wrote:
>> Many folks in this newsgroup have said: "I don't have to try it to
>> know it won't work." Frankly that attitude sounds like Bible thumping
>> to me. It's certainly not the attitude of a scientist or a skeptic.
>>
>
>Have fun learning dozens of assembly languages.
What if I said I had created a new kind of machine. The assembly
language of this machine was easier to use than Java. What if others
reported the same thing. What if there was a lot of hype about it?
Would you look at it? Would you try it? Or would you thump your
bible?
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
Carl Thronson
"David B Lightstone" <david.lightst...@prodigy.net> wrote in
message news:7Zb89.987$TI6.96...@newssvr17.news.prodigy.com...
>
> "Carl Thronson" <carlth...@yahoo.com> wrote in message
> news:3c72d700.02081...@posting.google.com...
> > Gerold Keefer <gke...@avoca-vsm.com> wrote in message
> news:<3D5FC337...@avoca-vsm.com>...
> > > Carl Thronson wrote:
> > >
> > >
> > > > 2. Test automation is a good thing. Again, I think this is just
> > > > common sense. It means you require less resources to execute tests.
> > >
> > > wrong. automation might cause more effort than manual testing,
> > > particularly when you do it wrong. brian marick wrote a paper about
> that.
> > > you frequently see negative ROI figures with test automation.
> > >
> >
> > Hmmm... I am really blown away by this. I have always believed
> > automating a task is better than doing it by hand. The number of
> > products on the market for automating tests suggests there must be
> > some truth in it. I'm also seeing a trend these days, where companies
> > just can't keep up with testing they need to do and so they are
> > shipping the work to other countries. Who is Brian Marick? Where can
> > I get his paper?
>
> His web site is
> http://www.testing.com/
>
> >
> for
> > > > the confusion. Try walking into the cubes of one your engineers
> > > > unannounced and look at their code. How well does the code conform
> to
> > > > best practices? That's what I mean by random testing.
>
> Oh the old "snap inspection" of the troops.
> I'm not sure what is being measured. Progress, whether the troops have
idle
> time.
>
If you have coding guidelines you can test for adherence to those
guidelines.
-Carl
David B Lightstone
"Uncle Bob (Robert C. Martin)"
news:j8m2mu01hooj3eece...@4ax.com...
> On Sun, 18 Aug 2002 00:28:34 -0400, Pat Kohli
> <kohliCUT...@ameritel.net> wrote:
>
> >Now we have vacuum tanks and experiments. eXperiments show that pair
programming reduces
> >efficency. Please act surprised for me.
>
> Some research indicates that PP is less efficient, other research
> indicates it is more efficient. There is slighly more research with
> the latter outcome than the former.
>
> I *like* pair programming. I do it whenever I can. I find it helps
> me think more clearly, and the code I produce with my partners is
> better than the code I produce alone. YMMV.
You drive up to the door, and fail to open it. Obviously the theory/model
has a significant flaw, otherwise it could be used to explain the different
results. Counting beans (number or research reports that support your
position) just doesn't cut it. We all know that the count can be stacked in
your favor by means of (accidental or otherwise) miscounting. Your alledged
bible thumper (thats sarcasm ) would say - is that science or politics or
marketing?
Perhaps the successful research reports are not realistic experiments (say
because they are studies of students learning how to program, rather than
studies of programs developed in an industrial environment)
Keith Ray
"Uncle Bob (Robert C. Martin)"
> However, C3 is old hat. There are a plethora of other XP project out
> there, so there's plenty of new observations to make.
For example...
<http://groups.yahoo.com/group/extremeprogramming/message/58491>
(Letter from stakeholder, 8/4/02)
Dear Agile/XP Community,
After our June 1 delivery date Wyatt asked if I would provide feedback
regarding my impressions of the Agile/XP process. He also informed me
that the growing Agile movement would benefit learning from individuals
who've experienced the process.
First, I want you to know that I do not consider myself technical by any
stretch of the imagination. However I know what I like, and what I want.
You should also know that I've never known whether a project was using a
waterfall process or an Agile process until I learned the difference.
It's my understanding that my previous experiences were waterfall.
As I'm writing and thinking aloud, I'm not sure if what I experienced
and enjoyed was the process or the people, or because of the process'
philosophy when applied with its disciplines brings out the best of
people, and instills confidence that the team will deliver, and deliver
meeting [my] expectations.
The bottom-line is that I appreciated the following:
- being able to steer development based on my business needs
- seeing working software sooner
- knowing when things were going to be completed
- being able to change my mind without it costing extra
- open communication without the "Chinese Wall" syndrome
- getting what I want the first time around
- knowing immediately the risks
What I found challenging:
- juggling my responsibilities at work and being available to test
- thoroughly testing the stories
- at times the brisk pace
What I learned:
- shorter and better story writing
- importance of testing often and not waiting till the end
- shorter iterations to keep me and the team focused on smaller issues
- having a separate QA team would have made everything easier
- it takes longer and costs more if testing is done late in the process
- I'm much happier if I'm involved with the development process
- there are consequences for not being involved
- as a client I have a Bill of Rights
I can say without hesitation that my first Agile/XP experience was most
enjoyable and rewarding. I was able to meet my business needs sooner, I
had the flexibility to modify my requests and I felt the quality of the
final product was a significant improvement over previous projects.
I would like to comment on the brisk pace of the team. Every two weeks a
new version of the application was pushed to our staging server ready
for me to test. I found this approach at times amusing because the
development team was completing Stories faster than I could actually
test them. This to me is remarkable, and a welcome change over
receiving an application three to four months down the road that doesn't
meet our expectations.
Without any doubt in my mind, Agile/XP is a tremendous process. Its
disciplines force[d] everyone to do the best job possible with the focus
on solving the immediate business problems and nothing more. I felt
that my needs were the primary concerns.
We have several new projects and we continue to refine the process
trying to find our performance sweetspot. At the moment we are working
in one week iterations, and this seems to work best for my testing
because it does not require so much of my time at the end, and it seems
best for the development team because the Stories are short enough to
make them manageable.
I look forward to continuing with the Agile process[es] and hope others
will embrace this wonderful approach to product development.
Sincerely,
M.D.
Phlip
> If you have coding guidelines you can test for adherence to those
> guidelines.
Suppose one of your guidelines is you never write a new line of code
without proving you can write a failing test that requests exactly that
line of code. In this case your own tests can't show if anybody cheated.
If you feel this is an issue in your project, you can use a test coverage
testing tool. TDD provides 100% statement coverage, and it provides branch
coverage only at the programmer's suspicion. So a test coverage testing
tool need only check the easy kind, statement coverage, to check if the
team is behaving. ;-)
--
Phlip
http://www.greencheese.org/ParodyMode
-- Proud victim of the dreaded boomerang effect --
David B Lightstone
> Carl Thronson wrote:
>
> > If you have coding guidelines you can test for adherence to those
> > guidelines.
>
> Suppose one of your guidelines is you never write a new line of code
> without proving you can write a failing test that requests exactly that
> line of code.
Other than Philip - does anybody consider such a guideline even remotely
realistic?
Phlip
> > without proving you can write a failing test that requests exactly that
> > line of code.
>
> Other than Philip - does anybody consider such a guideline even remotely
> realistic?
Never write a line of code unless you can write a line in a test that fails
because the code does not exist.
You could read a book about this simple and obvious technique:
http://groups.yahoo.com/group/testdrivendevelopment/files/
Its author and all its reviewers use the technique successfully.
Or you could go on running at the mouth. When you claim to be smart enough to
debunk XP, then manage to prove you don't know _literally_ the first thing
about it, you don't win much credibility.
--
Phlip
Carl Thronson
Suppose one of your guidelines is you don't use magic numbers. How do you
test for that?
Let me digress just a wee bit.
I believe in tools. I believe in testing. I believe in managing the
process. But, I get a bit disturbed by the search for the "holy grail" of
methodologies.
Let me give you one very short story and one analogy to emphasize what I'm
trying to say.
When I was learning to drive in high school, we drove in pairs - one
instructor and two kids. My classmate was driving down the freeway when the
instructor asked her if she wanted to try the cruise control. She turned it
on, leaned back, and let go of the steering wheel. The point being that
aids such as tools or methodologies can help; but, you should never let go
and rely solely on the aid.
The search for newer and better methodologies reminds me of an old friend.
He was always talking about new religions he discovered. Each one was
better than the one before. Each one did a better job of explaining the
world around us and the human condition and what we should do to improve our
lives and all that. More importantly each one was easier for him. He would
rather have the religion change for him than for him to have to change for
the religion. The point being that what it takes to develop software has
not changed much since the beginning. The general principles are the same.
We keep looking for a system we can adopt whereby individuals can avoid the
hard work they need to do. Just like my friend was seeking a religion where
he could avoid the hard work he needed to do.
-Carl
David B Lightstone
"Phlip" <phli...@my-deja.com> wrote in message
news:hOu89.2663$lL2.15...@newssvr14.news.prodigy.com...
> > > Suppose one of your guidelines is you never write a new line of code
> > > without proving you can write a failing test that requests exactly
that
> > > line of code.
> >
> > Other than Philip - does anybody consider such a guideline even
remotely
> > realistic?
>
> Never write a line of code unless you can write a line in a test that
fails
> because the code does not exist.
I guess you could say that something mentioned to me by D L Parnas a long
time ago still sticks in my mind. But then realistically you would not
believe that.
It is not realistic to expect people to follow a methodology at all times.
One can, however, expect people to post mortum there works and
document/reengineer it such that it is consistent with their choosen
methodology.
Do you really believe that people are going to follow such a guideline with
the diligence that it demands? Problem solving just doesn't happen that
way. Maybe you are so diligent that you have no comprehension of the
realities imposed upon mortal human being. I neither know or frankly care
to know.
>
> You could read a book about this simple and obvious technique:
>
> http://groups.yahoo.com/group/testdrivendevelopment/files/
>
> Its author and all its reviewers use the technique successfully.
>
I have no doubt that they use it successfully. That does not however make
the guideline a realistic one. It only means that they are sufficiently
diligent to follow the guideline. Waterfall is also a good guideline if you
follow it. Problem is that nobody ever follows waterfall. Same will be
true with any method/methodology you choose to favor.
>
> Or you could go on running at the mouth. When you claim to be smart
enough to
> debunk XP, then manage to prove you don't know _literally_ the first
thing
> about it, you don't win much credibility.
You are the only one here who thinks I am even attempting to debunk XP.
Just pointing out an anomalies in need to being understoud. If as a result
of either considering the question, someone thinks less about XP well they
have their reasons.
Take the silly guideline mentioned as an example. Do you really think it is
realistic?
>
> --
> Phlip
>
>
Jeff Grigg
> > Suppose one of your guidelines is you never write a new line of code
> > without proving you can write a failing test that requests exactly
> > that line of code.
"David B Lightstone" <david.lightst...@prodigy.net> wrote...
> > Other than Philip - does anybody consider such a guideline even
> > remotely realistic?
Sure. I do.
You're in the Extreme Programming usenet news group. Most of us not
only think it's realistic, we do it. Pretty much all the time.
> "Phlip" <phli...@my-deja.com> wrote...
> > Never write a line of code unless you can write a line in a test that
> > fails because the code does not exist.
"David B Lightstone" <david.lightst...@prodigy.net> wrote...
> [...]
> Do you really believe that people are going to follow such a guideline with
> the diligence that it demands? Problem solving just doesn't happen that
> way. Maybe you are so diligent that you have no comprehension of the
> realities imposed upon mortal human being. [...]
hahahaha. Why thank you.
But really; try it. You'll find that it's not all that difficult.
And if you also do Pair Programming, you'll find it even easier.
> "Phlip" <phli...@my-deja.com> wrote...
> > You could read a book about this simple and obvious technique:
> > http://groups.yahoo.com/group/testdrivendevelopment/files/
> > Its author and all its reviewers use the technique successfully.
"David B Lightstone" <david.lightst...@prodigy.net> wrote...
> I have no doubt that they use it successfully. That does not however make
> the guideline a realistic one. It only means that they are sufficiently
> diligent to follow the guideline. Waterfall is also a good guideline if you
> follow it. Problem is that nobody ever follows waterfall. Same will be
> true with any method/methodology you choose to favor.
Yes, no methodology is perfect. And no methodology will ever be
applied perfectly. But if you abandon them all, you are left with
nothing but chaos. And chaos doesn't have a very good track record of
producing quality systems.
If you're not sufficiently diligent to follow any guideline, you'll
have trouble: At work, at home, with the law, etc. ;-)
Consider this:
Learning to play the piano well takes hard work. Lots of hard work.
*BUT* just walking up to a piano and banging on the keys harder and
harder won't get you there. "Working harder" won't always get you the
best results. Sometimes other guidelines can be *very* helpful to
getting better results.
Keith Ray
"David B Lightstone" <david.lightst...@prodigy.net> wrote:
> I have no doubt that they use it successfully. That does not however make
> the guideline a realistic one. It only means that they are sufficiently
> diligent to follow the guideline. Waterfall is also a good guideline if you
> follow it. Problem is that nobody ever follows waterfall. Same will be
> true with any method/methodology you choose to favor.
Unlike some other practices, test-first done XP-style is very rewarding.
Combined with pair programming to help remind you to keep to the
practice (and the two-heads benefit for thinking about tests to write),
it can be fun.
Yes, FUN.
Search the internet for "test infected".
Pat Kohli
Phlip wrote:
> [Follow-ups set to the XP newsgroup]
>
>
> C3 was Chryslers attempt to learn OO programming. To do this, they threw
> their hardest problem at hired guns. Don't do that; start with a small, but
> not trivial, project.
>
I understand that payroll is not an entirely trivial application, but don't tell
me that was the hardest computer application at Chrysler!!!!!
>
> The end-users of the C3 source had no motivation to switch to it; they
> weren't the same group as the ones who hired the guns. Don't do that.
>
Sounds fair.
>
> C3 failed because it was prevented from trying the "frequent releases" rule
> to see if it would work. The team created perfectly good releases which the
> customers installed very infrequently. Don't do that, even if you are not
> using XP.
>
Some users do not like frequent revisions to their software. One of the nice
things about planning incremental releases and the features that will be
available in each one, is that such a scheme empowers the users to select which
releases they are interested in using and which ones they are not. Presumably
in the case of a company's payroll, though, either the department uses a given
release, or no one does.
As an OO vehicle, one can only guess how well C3 succeeded. OO ought to promote
inheritance, code reuse, and other facets which should be anathema to the
religious refactoring which pursues the minimal code to yield the current
functionality. As far as a database to pay 80,000 Chrysler employees goes, a
novice programmer can tell you that if you design a database to support just the
first release of 12,000 some folks, you _will_ index them on a short integer,
and when you go to a release to support 80,000 some folks, you will index them
on a long integer. Thus, I hope we can all see that to both minimize the first
release, and subsequently support the actual requirement, we will need another
program to rebuild the personnel table from the short index index to the long
integer index - an introduction of needless complexity, soleley to satisfy the
myopia of XP. Do I hear a "Don't do that"?
>
> >> Many folks in this newsgroup have said: "I don't have to try it to
> >> know it won't work." Frankly that attitude sounds like Bible thumping
> >> to me. It's certainly not the attitude of a scientist or a skeptic.
> >
> > Have fun learning dozens of assembly languages.
>
> This is a matter of orders of magnitude. The productivity boost using a
> very high level language is around 100 to 1.
>
For those other than Uncle Bob (who knows twice as many assembly languages as
YT), it is a matter of common sense. Since I'm not sure where you sit in the
galaxy:
1. Not everyone has control of a customer, to put into the development site;
not everyone is confident that if they got such an ombudsperson, it would be one
of sufficient insight to steer development through customer needs and to sell
any compromises to the user community.
2. Not everyone has confidence that such a person could stay in such a role
indefinetely.
3. Not everyone (maybe just Chrysler) can afford a multi-man-year, multi-person
software experiment, to just see if some process can work despite the wisdom of
experience and multiple indications that the process could not succeed.
4. Some live in a world of paper, of contracts, and written agreements. In such
a world, documented requirements, interface control documents, and the like
provide 'treaties' which endure long after the parties which negotiated them
have moved on. They outlast handshakes, and are maintained by the
organizations, and departments which agreed to them.
5. In such a world, of order which can endure longer than a personal
relationship, a design which phases in features, can appease the organizational
aspirations of diverse departments operating on limited budgets, with growing
needs.
6. Such a world demands progress. Progress is not just change, but change which
is anticipated by those who have invested in it, change which is controlled, and
change which can be redirected, on consent of the parties, not just a single
customer's rep.
>
> If I thought of a technique that could give a productivity boost of from
> 0.5 to 5 times, which was easy for you to try, which was easy for you to
> measure, which never yielded a false positive, which showed failure very
> simply and cleanly, then it would be remiss of me not to recommend you try
> it.
>
W/o knowing how efficient I am, you really have no way of knowing how
inefficient your proposal could be, so I would be remiss in giving your claims
of productivity boost _any_ credence.
>
> And it would be remiss of you not to try it.
Try a water tower.
> If you were a CMM Level 5
> company and you did not at least attempt an XP-style project (or any other
> known style) you would risk losing your certification for "not
> experimenting with your process to improve it."
So, you work at Carnegie-Mellon, or do you just play one on usenet?
toodles!
ko...@ameritel.net
Jeff Grigg
> > Pat Kohli <kohliCUT...@ameritel.net> wrote:
> > >Now we have vacuum tanks and experiments. eXperiments show that pair
> > >programming reduces efficency. Please act surprised for me.
> "Uncle Bob (Robert C. Martin)" wrote...
> > Some research indicates that PP is less efficient, other research
> > indicates it is more efficient. There is slighly more research with
> > the latter outcome than the former.
"David B Lightstone" <david.lightst...@prodigy.net> wrote...
> You drive up to the door, and fail to open it. Obviously the theory/model
> has a significant flaw, otherwise it could be used to explain the different
> results. [...]
I think it's quite easy to explain the different results:
As a low bound, a pair that doesn't work well together is probably no
better than one of them working alone. If one of them took a nap
while the other worked, one would expect a work rate of "one times
that of one working alone." ...because that's what you have -- one
person working alone.
For a high bound, a productivity difference of ten times between
"good" and "bad" programmers in the industry has been reported in many
places. (I've seen it most recently measured in C++ programming
contests.)
So I think there's good reason to believe that a pair doing
particularly well could produce ten times the norm for an individual.
(And my personal observations are that the differences can be several
orders of magnitude -- not limited to 10 times.)
So, we could easily expect that any given test of Pair Programming
could easily measure a productivity of "one times" ("twice as
expensive"; the Nawrocki study) to ten times. I've seen studies
showing "1x" (Nawrocki), "2x" (the Williams study) and "4x". I think
this shows that "2x" is possible, and that it's not the upper limit.
Is "10x" the upper limit? Is there an upper limit? I don't think we
can conclude anything about a possible upper limit from the given
scientific studies.
There's substantially more informal evidence than scientific studies
on this matter. And the scientific studies, taken together, pretty
much support the idea that you won't lose anything by doing Pair
Programming, unless you do a bad job of it.
And you can do a bad job of just about anything, and mess up your
project.
"David B Lightstone" <david.lightst...@prodigy.net> wrote...
> Perhaps the successful research reports are not realistic experiments (say
> because they are studies of students learning how to program, rather than
> studies of programs developed in an industrial environment)
I don't think any of the research reports are very realistic. Not the
"1x" Nawrocki report, nor the "4x" report (that I don't happen to have
handy right at the moment; sorry! ;-) The projects were all too
short, and participants too inexperienced.
However, "realistic" experiments, with projects of a significant size,
and members with significant experience, would be remarkably expensive
to conduct. And you couldn't do them "double blind," as practically
any experienced practitioner would know if they're using a traditional
or agile approach.
So, as with many other decisions we make in our lives, we may just
have to rely on experience, and the advice of others who have been
there. Fortunately, most people's experience with XP has been good.
Maybe you otta' try it. ;->
Pat Kohli
I think we've hit on a winning means of discourse. Keep up the trick questions.
Ron Jeffries wrote:
> On Sun, 18 Aug 2002 00:02:42 -0400, Pat Kohli <kohliCUT...@ameritel.net>
> wrote:
>
> >> Have you tried it enough to
> >> get good at it?
> >
> >Ron, Ron, Ron, pair programming is not something I can get good at, just by me by trying
> >it. It is done in pairs and some pairs are just going to be more productive than others and
> >then we switch. Would you care to try another trick question on me?
>
> Yes. Have you tried it with enough people to know that?
How many people do I need to try it with to know that it is done in pairs, and some pairs are
just going to be more productive than others?
Here I go again, using my brain: I would have thought that I could anticipate that productivity
of one pair with me could be better than productivity in another pair with me. Really, do you
need to PP with me and Kent and Uncle Bob and one other, or one thousand others before you
realize that we just don't get much done but exchanging trick questions, while when you are
thumping with Uncle Bob, the KSLOC count just keeps a jumping away. I'm figuring already that if
I were paired w/ my programmer buddy, we would do _way_ more than if I were paired w/ some
software engineer that doesn't program at all anymore. I'm not any better or worse when I am in
a more or less productive pair; it is just one of those things.
So, I don't think it is a matter of trying it. I think I should do my work, and when folks
suggest that I should develop new systems as if I were a maintenance programmer w/ a conjoined
twin, my response is 'try a water tower'.
tahtah!
-ko...@ameritel.net
Phlip
>
> Search the internet for "test infected".
Of all the gloves to throw down on this newsgroup...
Someone is really off his form today!
--
Phlip
http://www.greencheese.org/ParodyMode
-- Whip me. Beat me. Make me install Oracle. --
Bill Turner
"Uncle Bob (Robert C. Martin)" wrote:
> On Tue, 13 Aug 2002 23:48:02 -0400, Pat Kohli
> <kohliCUT...@ameritel.net> wrote:
>
> >When someone at my day job tries
> >to convince my boss that things will get easier if we forget about documenting
> >requirements (they are going to change anyway!), forget about those UML diagrams, and
> >just start coding up those tests, in pairs ... I get an attitude. Someone has just made
> >a good challenging job, really even harder than it needed to be, and they made it harder
> >for me to get good software to my customers.
>
> Your point seems obvious. I don't blame you for your reaction. On
> the other hand, it was obvious to Aristotle that heavier things must
> fall faster than lighter things.
While Aristotle did get many scientific things wrong, specifically not developing a method to
verify theories, he did develop a system of logic that is still today quite useful and can be
used in many situations. This is called syllogism. If not for this, we could not draw any
valid conclusions from our experiments and observations.
>
>
> There are people out there trying XP and reporting success. You can
> scoff, or you can observe, or you might even try a few experiments on
> your own.
Personally, I have tried XP. There were many issues, which I do not wish to re-hash again.
Suffice it to say that I have grown more skeptical. This doesn't mean that XP is completely
wrong. I am looking for studies to be published in peer reviewed magazines, and am waiting
for a few other factors to re-align themselves before giving it another attempt. The
anecdotal evidence seems quite strong, but one must wonder why the enthusiasm. It could be
for any number of factors that have nothing to do with really delivering quality, as defined
by customer satisfaction, and defined by post implementation cost.
In the meantime, I will continue to work towards improving the state of our "plan driven"
software engineering practices.
>
>
> Many folks in this newsgroup have said: "I don't have to try it to
> know it won't work." Frankly that attitude sounds like Bible thumping
> to me. It's certainly not the attitude of a scientist or a skeptic.
Just as those who say, "Trust me, it works", sound like snake oil salesmen.
Bill
David B Lightstone
"Jeff Grigg" <jgr...@mo.net> wrote in message
news:c794c0fd.02082...@posting.google.com...
I consider that to be a plausible, but unsubstanciated explination. The
operational word is unsubstanciated. Plausible is being used in the same
sense of an attorney (to convince the jury to give the client the benifit
of a doubt). Explinations of word semantics (as poor as they are) provided
for Philip who occasionally misunderstands and goes ballistic
Somehow I find it difficult for one of the pair to take a nap or go off
into a fantasy land of senseless thought. It would be noticed.
I will give you an equally plausible (and equally rediculus explination).
Although described as an error risk reduction strategy, pair programming is
little more than a strategy to focus the attention of the employee. It
focuses them on the task at hand by depriving them of the opportunity to
gaze at the clock; get distracted by the pretty secretary as she walks by
(assuming the programmer to be a 22 year old male); comment about the
weather to the guy in the next cube; walk over to the coffee machine or
soda machine to get something to drink; etc. In essense your pair is your
personal overseer. The low productivity teams realize this and conspire,
the high productivity teams don't. Naturally this scenario will be disputed
with the simple claim, that spirts are high amongst pair programmers;
stress is lower; congeniality is high; it is a good whole some work
environment. (the employees have been selected for compliance with the
demands of the workplace, their chemistry is good)
>
> So I think there's good reason to believe that a pair doing
> particularly well could produce ten times the norm for an individual.
> (And my personal observations are that the differences can be several
> orders of magnitude -- not limited to 10 times.)
>
> So, we could easily expect that any given test of Pair Programming
> could easily measure a productivity of "one times" ("twice as
> expensive"; the Nawrocki study) to ten times. I've seen studies
> showing "1x" (Nawrocki), "2x" (the Williams study) and "4x". I think
> this shows that "2x" is possible, and that it's not the upper limit.
>
> Is "10x" the upper limit? Is there an upper limit? I don't think we
> can conclude anything about a possible upper limit from the given
> scientific studies.
Wild speculation
>
> There's substantially more informal evidence than scientific studies
> on this matter. And the scientific studies, taken together, pretty
> much support the idea that you won't lose anything by doing Pair
> Programming, unless you do a bad job of it.
>
> And you can do a bad job of just about anything, and mess up your
> project.
>
>
> "David B Lightstone" <david.lightst...@prodigy.net> wrote...
> > Perhaps the successful research reports are not realistic experiments
(say
> > because they are studies of students learning how to program, rather
than
> > studies of programs developed in an industrial environment)
>
> I don't think any of the research reports are very realistic. Not the
> "1x" Nawrocki report, nor the "4x" report (that I don't happen to have
> handy right at the moment; sorry! ;-) The projects were all too
> short, and participants too inexperienced.
It is good to observe that not all the XP advocates consider the "research"
in pair programming to be validating. In the parlance of the choosen
"method" perhaps you should pair up with the more and less experienced. The
conclusions which they reach are not substanciated by the evidence. This in
and of itself this begs a number of serious questions. Most important:
(1) Just how faulty are their programs? (debugging is often an inferential
process, if you reach unsubstanciated conclusions with problem A, quite
likely you will exercise the same reasoning strategies when attempting to
debug program B)
(2) Assuming programs are not faulty - Just how disengenuous are the
advocates being?
Either does not bode well for adoption but those who are observant enough
to ask the questions
>
> However, "realistic" experiments, with projects of a significant size,
> and members with significant experience, would be remarkably expensive
> to conduct. And you couldn't do them "double blind," as practically
> any experienced practitioner would know if they're using a traditional
> or agile approach.
>
> So, as with many other decisions we make in our lives, we may just
> have to rely on experience, and the advice of others who have been
> there. Fortunately, most people's experience with XP has been good.
> Maybe you otta' try it. ;->
It always comes down to a leap of faith doesn't it? Such is the problem
with marketing innovation.
Ron Jeffries
<david.lightst...@prodigy.net> wrote:
>You drive up to the door, and fail to open it. Obviously the theory/model
>has a significant flaw, otherwise it could be used to explain the different
>results.
I'm aware of no substantive theory, as yet, for why pair programming works.
There are descriptions by various people of their experience. So certainly the
existing theory is flawed, mostly in being absent.
>Counting beans (number or research reports that support your
>position) just doesn't cut it. We all know that the count can be stacked in
>your favor by means of (accidental or otherwise) miscounting. Your alledged
>bible thumper (thats sarcasm ) would say - is that science or politics or
>marketing?
Well, it isn't marketing: we're not making any money selling pair programming.
It's not politics, because we're not running for election.
I think the work that has been done in measuring pair programming has probably
been at attempt at science.
>
>Perhaps the successful research reports are not realistic experiments (say
>because they are studies of students learning how to program, rather than
>studies of programs developed in an industrial environment)
Certainly experiments on students are unrealistic in some ways. All the
experiments so far are unrealistic in one way or another. In the community of
people who actually try it in their own work, long enough to develop the skill,
the reports are almost invariably positive. I think that's very interesting.
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
<david.lightst...@prodigy.net> wrote:
>> Suppose one of your guidelines is you never write a new line of code
>> without proving you can write a failing test that requests exactly that
>> line of code.
>
>Other than Philip - does anybody consider such a guideline even remotely
>realistic?
Yes. I try to work that way all the time. When I'm on my game, which is usually,
I hope, all the code is written in response to a failing test.
I think that Phlip, in his way, expresses the thing a bit strongly. There may be
several lines needed to make the failing test work, and there may be several
different combinations of lines.
For example, suppose I have a test that requires some class, say EmployeeSet, to
count its entries. The test might look like this (untested code, merely a
sketch):
[Test] public void EmployeeCount() {
EmployeeSet es = new EmployeeSet();
AssertEquals(0, es.count);
es.Add(new Employee(...));
es.Add(new Employee(...));
AssertEquals(2, es.count);
}
The implementation of count might be to count them on the way in, or to count
them right when asked. It might include the line of code
EmployeeCount++;
or the line
EmployeeCount = EmployeeCount + 1;
or the line
return EmployeeCollection.Length;
Whichever of those implementations is chosen, it is nonetheless driven by the
test. We keep adding tests, and improving the implementation, until the job is
done.
This may sound like an odd and awkward process, but in practice it is not. There
are some example articles about it on my web site that might help, and what
really helps is to try it. I've found Test-Driven Development (its full name) to
be a very useful addition to my bag of tricks.
Regards,
Ron Jeffries
<david.lightst...@prodigy.net> wrote:
>> Suppose one of your guidelines is you never write a new line of code
>> without proving you can write a failing test that requests exactly that
>> line of code.
>
>Other than Philip - does anybody consider such a guideline even remotely
>realistic?
Second reply upon reading your "conversation" with Phlip.
Your objection seems to be that the guideline is not realistic because people
will sometimes not follow it.
Seems to me that this is the history of all guidelines. No one follows the
coding standards all the time. Most people exceed the speed limit sometimes.
(Everyone on I-96 apparently does.) Some people kill or commit adultery,
although surely no one here.
The point of a guideline like Phlip mentions is to set a standard. The style of
standards that the XP community sets is to set them high, unattainable except
when we're perfect, which will apparently be a long time coming.
I can't think of a good way of phrasing the guideline that directs the
test-first discipline that wouldn't be subject to your objection, yet still
communicates the very high value that the technique has.
Can you suggest one?
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:g5v6mugo9boeej6a1...@4ax.com...
> On Tue, 20 Aug 2002 11:25:58 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >You drive up to the door, and fail to open it. Obviously the
theory/model
> >has a significant flaw, otherwise it could be used to explain the
different
> >results.
>
> I'm aware of no substantive theory, as yet, for why pair programming
works.
> There are descriptions by various people of their experience. So
certainly the
> existing theory is flawed, mostly in being absent.
>
> >Counting beans (number or research reports that support your
> >position) just doesn't cut it. We all know that the count can be stacked
in
> >your favor by means of (accidental or otherwise) miscounting. Your
alledged
> >bible thumper (thats sarcasm ) would say - is that science or politics
or
> >marketing?
>
> Well, it isn't marketing: we're not making any money selling pair
programming.
> It's not politics, because we're not running for election.
Do you really consider those usages of the terms marketing and politics to
be reasonable?
I don't, but see no significant reason for discussing them
>
> I think the work that has been done in measuring pair programming has
probably
> been at attempt at science.
> >
> >Perhaps the successful research reports are not realistic experiments
(say
> >because they are studies of students learning how to program, rather
than
> >studies of programs developed in an industrial environment)
>
> Certainly experiments on students are unrealistic in some ways. All the
> experiments so far are unrealistic in one way or another. In the
community of
> people who actually try it in their own work, long enough to develop the
skill,
> the reports are almost invariably positive. I think that's very
interesting.
So the learning curve is extensive. I find that to be more interesting. It
means attempting a significant project without a well prepared and trained
development team would indeed be a very risky venture.
David J. Aronson
Carl Thronson wrote:
> Gerold Keefer <gke...@avoca-vsm.com> wrote
...
> Hmmm... I am really blown away by this. I have always believed
> automating a task is better than doing it by hand.
As a general rule, yes, especially for things that are going to be done
over and over a gazillion times. However, *sometimes* the effort
required to automate it once, is even more than the cumulative effort of
redoing it manually over and over.
> > if you are performing the *same* tests all the time
> > you are only checking that what used to work, still works.
> > if you change your software this is of very limited use to have a
> > trend.
>
> I disagree. I think it's very important to make sure what used to
> work still works.
Sure. Regression testing. However, it's not all the testing you ever
need.
> Suppose you own a construction company. Suppose you hired the
> cheapest day laborers you can find.
If you hire the cheapest you can find, you get what you darn well
deserve! From here out, though, let us suppose you're looking for the
best "bang for the buck", not simply the least buck.
> They don't have licenses or references.
>
> I think there's only 2 things that matter.
>
> Do they know what they're doing? Watch them for a while and you will
> find out.
Some basic questions in a brief interview should give you a decent idea
of that.
> Will they take short cuts when you're not looking? Surprise
> inspections should fix that.
...and make them think (or rather, realize) that you don't trust them,
so why should they trust you, and morale goes down the tubes. Instead,
you can make a full inspection of the work at some logical point, as
frankly I would expect. This will also help you decide whether they
knew what they were doing. To analogize back to software, this could
correspond to code reviews, unit tests, system tests, or any number of
other very standard (at least in theory) procedures, depending on just
when and how the inspection is done.
--
David J. Aronson, Software Engineer for hire in Philadelphia area
Resume, and other details, online at: http://dja2001.home.att.net
Looking for work in Philly? Check out the Yahoo group PhillyJobs.
David J. Aronson
"Uncle Bob (Robert C. Martin)" wrote:
>
> On Sun, 18 Aug 2002 00:28:34 -0400, Pat Kohli
> <kohliCUT...@ameritel.net> wrote:
...
> >Have fun learning dozens of assembly languages.
>
> Lets see... I know BAL/360, PDP8, PDP11, 8080, 8086, M365,
> Varian/620, 6502, perhaps a few more. It *is* fun. Not only is it
> fun, but it can be very useful.
Useful, I can understand -- barring an absolutely perfectly optimizing
compiler, nothing can match the speed and tightness of handcrafted
assembler. But "fun"? This is obviously some strange usage of the wod
/fun/ that I wasn't previously aware of.[0] Could you please explain
about the fifty ways, er, I mean, how coding something in assembler,
rather than a higher level language (generally far faster to write, less
prone to errors, etc.) is fun? Maybe you get a big enough kick out of
seeing how fast and small you can make the code, to make up for the
drawbacks?
> 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
And even the most ludicrous ideas can turn out to be right, or at least
shed an interesting new light on things.
[0] Apologies to Douglas Adams.
Hoff, Todd
only metric of importance? If it is more efficient
is it more efficient for every person? Even if it is less
efficient am i allowed to be less efficient if it makes
me happier? Efficiency is a harsh god.
--
It's only when your cage is rattled do you realize you are in a cage.
Uncle Bob (Robert C. Martin)
<ronje...@REMOVEacm.org> wrote:
>Certainly experiments on students are unrealistic in some ways. All the
>experiments so far are unrealistic in one way or another. In the community of
>people who actually try it in their own work, long enough to develop the skill,
>the reports are almost invariably positive. I think that's very interesting.
To amplify Ron's point: All experiment are *always* unrealistic. The
fact that I drop a ball today, and observe that it falls, does not
mean that it will fall when I drop it tomorrow.
When we have *many* experiments we *may* be able to come up with a
theory that explains our observations and successfully predicts future
observations.
Right now all we have are a few data points.
Ron Jeffries
<david.lightst...@prodigy.net> wrote:
>So the learning curve is extensive. I find that to be more interesting. It
>means attempting a significant project without a well prepared and trained
>development team would indeed be a very risky venture.
Isn't it usually a very risky venture to attempt a significant project without a
well prepared and trained development team?
It's called Extreme Programming, not Miraculous Programming. And the practices
are called that, in part, because you have to practice them.
Pretty much everything in our business requires a significant learning curve.
Learning is what distinguishes the good ones from the bad ones, in my opinion.
The XP practices are good things to learn. Having learned them, one is better
qualified to judge when and where to use them than when one hasn't learned them.
Does that compute? If not, how can I further explain?
Phlip
> Does that compute? If not, how can I further explain?
Come to think of it, "Mutual Programming", where one coder writes the code
and another the tests is the method of choice at that bastion of squeaky
clean code and thrifty processes, Microsoft.
--
Phlip
http://www.c2.com/cgi/wiki?RatAndTuyen
-- Appears that VIM is internationalized...
May I ask what's the point? --
Bill Turner
David B Lightstone wrote:
It seems clear that the reasons for the increase in productivity is unclear.
Your explanation is just as plausible as any others I have heard, one that I
had thought of also, and is possibly more believable. Continuing to study pair
programming to identify just what it is that makes certain teams more
productive is important. We may find that it has little to do with having a
back seat driver.
Question. Why would only 22 y.o. males be distracted by a pretty secretary? I
am 43. I get distracted. :-)
Bill
Bill Turner
"Hoff, Todd" wrote:
> Does it have to be either or? And is efficiency the
> only metric of importance? If it is more efficient
> is it more efficient for every person? Even if it is less
> efficient am i allowed to be less efficient if it makes
> me happier? Efficiency is a harsh god.
Efficiency is a harsh god, no doubt. Who decides whether or not you can
be less efficient? Certainly the investors want the best return on their
investment, so they want the best efficiency. Do you have a choice?
Probably not in a society that does not value worker's rights very
highly, as in the U.S. (I am an American, love America, and can recognize
it's shortcomings). According to an Economist magazine publication of
about two years ago, Americans work longer hours than workers in any
other developed country in the world. Also, according to "Wealth and
Democracy", the American worker has less leisure time now than they did
in the 70's, and it has been dropping steadily. Ever hear of white collar
slavery? Certainly, I have felt this way at times. "Work 60 hours or we
will find someone else who will" is the unspoken message to many hear. I
digress. Sorry. I'll get off my soapbox now.
Bill
Bill Turner
Ron Jeffries wrote:
Anecdotal evidence can point to valid conclusions. Sadly, anecdotal evidence is
frequently wrong in its assessment of results, and is even more likely to be wrong
when explaining why the results were achieved. People frequently delude themselves
(see "Extraordinary Popular Delusions & the Madness of Crowds" by by Charles
MacKay, Andrew Tobias). Could this be the case? Could it be that pairs enjoy
working as a team, therefore are deluding themselves about how well it does work?
I definitely want to see more research in this area. I guess I like hard evidence.
Until then, the pair programming controversy will continue.
Bill
Ron Jeffries
<51004898135...@t-online.de> wrote:
>I definitely want to see more research in this area. I guess I like hard evidence.
>Until then, the pair programming controversy will continue.
Suppose there were hard evidence saying that in a wide range of situations, PP
gets the same amount of work done, compared to programming alone, and that the
quality is higher. Think hard, imagine that you just read definitive research to
that effect.
What would you do differently from what you're doing today?
David B Lightstone
"Bill Turner" <51004898135...@t-online.de> wrote in message
news:3D647DAC...@t-online.de...
Claimed increase in productivity!!!!!! For all I know the increase may just
be a matter of preception, a problem of observation related to the nature
of the experiement. Possibily equivalent to the discovery of cold fusioon
> Your explanation is just as plausible as any others I have heard, one
that I
> had thought of also, and is possibly more believable. Continuing to study
pair
> programming to identify just what it is that makes certain teams more
> productive is important. We may find that it has little to do with having
a
> back seat driver.
>
> Question. Why would only 22 y.o. males be distracted by a pretty
secretary? I
> am 43. I get distracted. :-)
They need more supervision, because they get distracted. Their desks are
closer to the managers :-)
>
> Bill
>
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Thu, 22 Aug 2002 08:18:10 +0200, Bill Turner
> <51004898135...@t-online.de> wrote:
>
> >I definitely want to see more research in this area. I guess I like hard
evidence.
> >Until then, the pair programming controversy will continue.
>
> Suppose there were hard evidence saying that in a wide range of
situations, PP
> gets the same amount of work done, compared to programming alone, and
that the
> quality is higher. Think hard, imagine that you just read definitive
research to
> that effect.
>
> What would you do differently from what you're doing today?
Didn't you just indicate that no such results are available?
If such results were available I am certain you would have SCREAMED it to
the world by now
Lets not suppose, lets stick to the things we know.
As for your suppose question, of course we will gladly stand in line to buy
the silver bullet.
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Wed, 21 Aug 2002 13:31:12 GMT, "David B Lightstone"
> <david.lightst...@prodigy.net> wrote:
>
> >So the learning curve is extensive. I find that to be more interesting.
It
> >means attempting a significant project without a well prepared and
trained
> >development team would indeed be a very risky venture.
>
> Isn't it usually a very risky venture to attempt a significant project
without a
> well prepared and trained development team?
Of course. It becomes a business tradeoff between improving the process a
la SEI (one of the accepted process improvement models) or adopting a new
process (examples include the "Agile" like Methods). With the XP pair
programming learning curve being difficult, improving a la SEI probably
will be safer. It really depends upon having a good understanding of the
tradeoffs and alternatives; and having a good evaluation (not self
performed) of the lay of the land.
David J. Aronson
Bill Turner wrote:
> Ever hear of white collar slavery? Certainly, I have felt
> this way at times. "Work 60 hours or we will find someone
> else who will" is the unspoken message to many hear.
It isn't always unspoken. I'm currently "between positions" and there
is one company whose Help Wanted ads I consistently pass by -- because
they state, flat-out, that 55-hour work-weeks are the norm, and will be
expected of all personnel. At one place I interviewed, the interviewer
said that although only 40 hours is officially considered the standard,
most people put in much more; he was proud of regularly putting in
120-hour weeks, and gave the impression that most put in at least 60.
Phlip
Bill Turner wrote:
> There could be several ways to interpret the cause of these failures,
> other than the choice of methodology. It is well documented that many
> organizations do not practice the well known best practices, for example.
> Also, from my personal experience, I have never been on a project that did
> not commit at least one, and usually several, of the
> classic mistakes as defined by Steve McConnell in "Rapid Development".
> Could it be that these failures you speak of have more to do with these
> other points than with the choice of methodology?
The secret word is "visibility".
The book /Rapid Development/ broadcasts the unfounded meme that "visibility
is expensive" as if this were a total fact of life. The book contains a few
time charts of a project, showing blackout periods and points of partial or
total visibility. It implies that periods of high velocity must be
invisible, and periods of high visibility must be slow. This meme appeals
to engineers trained to make trade-offs.
You can't steer what you can't see. But the book implies that attempts to
steer require visibility, which require slower speeds.
The meme "visibility is expensive" has the dishonor of being an implicit
assumption in many folks' behaviors. No matter how enlightened, they will
still tell you, "Don't bother the programmers about that until they finish
their current phase."
This is an example of an unacknowledged bad belief.
If you understand how "quality is cheaper", and "visibility is free", you
will disturb the programmers more often - hopefully daily.
> I am curious to know how XP improves the ability to follow best practices
> (the best XP practices, since XP does not follow many of the traditional
> ones)?
Can you think of a traditional "best practice" that impairs visibility
under the assumption that visibility must be expensive, so we must only pay
for a little of it?
How about one as innocent as "Give every programmer a separate office, so
they feel important"?
This is an example of latent, unacknowledged assumptions.
But it's the invisible process that hides other failures to follow a pet
methodology. Remember programmers are generally only as psychic as everyone
else - an invisible process will at least be a little obscure to them too.
> In an organization where senior management does a poor job of
> planning of for the future, everything is a crisis. Since that is out of
> the hands of the IT organization, I don't see how a methodology of any
> sort will help. In an organization that is chaotic in this fashion, senior
> management likely will not give the blessing or support improvement
> efforts because of all the emergencies. (Note that this is only one
> example of why an organization does not follow best practices.)
There's planning and then there's planning. Don't think chess; that's
deterministic with no random elements. Think Rogue; the character mode
dungeon crawl game. You run around in the dark drawing a map, eliminating
pests and collecting gadgets. Detailed planning of the next level is worse
than useless, but large scale planning is critical - "In one more level
there will be Rust Monsters, so change to leather armor now before going
downstairs."
> I am also curious to know how the practice of XP eliminates the classic
> mistakes. Again, I realize that many of the classic mistakes do not apply.
> But, many do.
Visibility is communication combined with feedback. The XP practice which
is least easy to slide is the 2-week (or so) iteration. Many elements of
the project are visible before then, but at the 2 week deadline you may
expect a small image of how the entire project will fair if you keep going
with the current team and actual practices.
One classic mistake is running with a high burn-rate forever on a doomed
project. If the project is not feasible for technical reasons, they should
be visible early. Early cancellation is not failure, it is a successful
feasibility check.
http://www.c2.com/cgi/wiki?AgilityTest
--
Phlip
-- Shock Value Added --
Troll_4
> Ron Jeffries wrote:
>
> > Does that compute? If not, how can I further explain?
>
> Come to think of it, "Mutual Programming", where one coder writes the code
> and another the tests is the method of choice at that bastion of squeaky
> clean code and thrifty processes, Microsoft.
Come to think of it, Automated tests, where the tests are performed by
computer programs is the method of choice at that bastion of squeaky
clean code and thrifty processes, Microsoft
What are you trying to suggest Phlip?
ma...@sandbridgetech.com
I've been seeing these exchanges going on, and I did a bit of probing;
however, I can't get a definite handle on a couple of issues:
- how much does productivity increase w.r.t.
a) the original productivity of the programmer(s) involved
[e.g. if the programmer was originally 10 kloc/year it goes up x%
vs. if the programmer was originally 50 kloc/year it goes up y%]
b) the size of the problem
[the total program was 10 klocs vs. 100 klocs]
c) the work per programmer (specially for medium-size 50-200kloc
projects)
d) the type of project (data-base queries vs. web vs. systems (e.g. OS
vs. real-time vs. embedded)
Can you please point me to some studies/sources?
Thanks
Mayan
Bill Turner
David B Lightstone wrote:
> > It seems clear that the reasons for the increase in productivity is
> unclear.
>
> Claimed increase in productivity!!!!!! For all I know the increase may just
> be a matter of preception, a problem of observation related to the nature
> of the experiement. Possibily equivalent to the discovery of cold fusioon
It was too early in the morning when I wrote the above. I was trying to say
"claimed increase". I do agree that it could be self-delusion.
Bill
Bill Turner
Ron Jeffries wrote:
> On Thu, 22 Aug 2002 08:18:10 +0200, Bill Turner
> <51004898135...@t-online.de> wrote:
>
> >I definitely want to see more research in this area. I guess I like hard evidence.
> >Until then, the pair programming controversy will continue.
>
> Suppose there were hard evidence saying that in a wide range of situations, PP
> gets the same amount of work done, compared to programming alone, and that the
> quality is higher. Think hard, imagine that you just read definitive research to
> that effect.
>
> What would you do differently from what you're doing today?
Well, if what you are describing is a world where the vast majority of studies are
saying the same thing, not an almost equivalent number of studies showing opposite
results, then I would be committing malpractice by not pairing, or at least attempting
to do so. Much has been said in this thread by people on both sides of the divide that
leads one to the conclusion that such a world does not exist today.
Bill
David B Lightstone
Bill,
I make the same sort of mistakes. It is one of the things which comes with
being a human being.
Perhaps I was over reacting, but there is a phenomena about which I suspect
many fall victim.
If you hear an erroneous claim often enough, you eventually suspend
critical judgement, and repeat it. It is an interesting tool used in
marketing and political rhetoric. This for purposes both of spinning things
and misdirecting.
>
> Bill
>
Jeff Grigg
> > [...] "Work 60 hours or we will find someone
> > else who will" is the unspoken message to many hear.
"David J. Aronson" <dja...@att.net> wrote...
> It isn't always unspoken. [...] Help Wanted ads [... that say "]
> 55-hour work-weeks are the norm, and will be expected of all personnel.
> [...]
Tough economy.
Years ago, while working at EDS, I watched a large corporate project
*REQUIRE* 6 day 60 hour weeks of all project members. No paid
overtime. (Actually, our team was working much more than that, but no
one even asked us to. ;-)
Have some sanity:
Bad management can easily create more problems than mere overtime can
cure. Work smarter.
Ron Jeffries
<51004898135...@t-online.de> wrote:
>> >I definitely want to see more research in this area. I guess I like hard evidence.
>> >Until then, the pair programming controversy will continue.
>>
>> Suppose there were hard evidence saying that in a wide range of situations, PP
>> gets the same amount of work done, compared to programming alone, and that the
>> quality is higher. Think hard, imagine that you just read definitive research to
>> that effect.
>>
>> What would you do differently from what you're doing today?
>
>Well, if what you are describing is a world where the vast majority of studies are
>saying the same thing, not an almost equivalent number of studies showing opposite
>results, then I would be committing malpractice by not pairing, or at least attempting
>to do so.
Right. I suspect that the "right" answer is "I'd try it and see if it worked for
me."
>Much has been said in this thread by people on both sides of the divide that
>leads one to the conclusion that such a world does not exist today.
I suggest that there's enough evidence to make it worth trying ... because lots
of people are trying it. And most of them seem to be thinking it works. They
could be on drugs, I suppose.
Pat Kohli
"Uncle Bob (Robert C. Martin)" wrote:
> On Tue, 20 Aug 2002 22:57:53 -0400, Pat Kohli
> <kohliCUT...@ameritel.net> wrote:
>
> >As an OO vehicle, one can only guess how well C3 succeeded. OO ought to promote
> >inheritance, code reuse, and other facets which should be anathema to the
> >religious refactoring which pursues the minimal code to yield the current
> >functionality. As far as a database to pay 80,000 Chrysler employees goes, a
> >novice programmer can tell you that if you design a database to support just the
> >first release of 12,000 some folks, you _will_ index them on a short integer,
> >and when you go to a release to support 80,000 some folks, you will index them
> >on a long integer. Thus, I hope we can all see that to both minimize the first
> >release, and subsequently support the actual requirement, we will need another
> >program to rebuild the personnel table from the short index index to the long
> >integer index - an introduction of needless complexity, soleley to satisfy the
> >myopia of XP. Do I hear a "Don't do that"?
>
> The language was smalltalk in which all integers are of unlimitted
> size.
>
> In general, however, I disagree with your statement. You are
> suggesting that forethought can prevent change.
No. I would not suggest that forethought can prevent change, I would suggest that
forethought can focus the change where it meets the customers' needs, rather than
compensate for my lack of preparation.
>
>
> Yes, if we were writing in 16 bit C, and if we presumed that the
> database was adequate for 12,000 employees, and if later we needed to
> support 80,000, there would likely be a need to convert the database.
>
C is not an OO language. Though SmallTalk might implement integers of unspecified
size - I'm not familiar with it; other OO languages, such as C++ and Java, do have
sized integers, and relational files usually allocate a fixed size record w/in each
table, regardless of what language the application was written in.
>
> So what? Convert the database.
>
Thank you; you've scheduled a task which simply accomodates your own lack of
foresight, rather than serving your customers' needs - and you don't even seem to see
a problem with that. Enjoy XP, but don't presume that everyone will enjoy it when
their customers figure out that the programmers are making work for themselves. Do
I hear a "Don't do that"?
Phlip
Pat Kohli wrote:
> No. I would not suggest that forethought can prevent change, I would
> suggest that forethought can focus the change where it meets the
> customers' needs, rather than compensate for my lack of preparation.
You are requesting the Open Closed Principle.
We say that code constantly cleaned and pruned will exhibit true OCP in all
the places where it has previously been changed, and will have saturated
tests and simple code making unforseen changes safe.
In our experience, anything else adds risk. Premature generalization is the
root of much evil.
>> So what? Convert the database.
>
> Thank you; you've scheduled a task which simply accomodates your own lack
> of foresight, rather than serving your customers' needs - and you don't
> even seem to see
> a problem with that. Enjoy XP, but don't presume that everyone will enjoy
> it when
> their customers figure out that the programmers are making work for
> themselves. Do I hear a "Don't do that"?
Because we abhor duplication, database accesses that all look similar will
be encapsulated and reused. This point of re-use will be the place where
the new database will be installed. This defers expense until the last
possible cheap moment; it's what engineers do (except the most newbescent
ones).
--
Phlip
http://www.greencheese.org/PeaceAndCalm
-- Set phasers on illin' --
Pat Kohli
"Uncle Bob (Robert C. Martin)" wrote:
> On Tue, 20 Aug 2002 22:57:53 -0400, Pat Kohli
> <kohliCUT...@ameritel.net> wrote:
>
> >1. Not everyone has control of a customer, to put into the development site;
> >not everyone is confident that if they got such an ombudsperson, it would be one
> >of sufficient insight to steer development through customer needs and to sell
> >any compromises to the user community.
>
> And yet, every project needs someone who can steer it. Every project
> needs some person, or group of people, who have the authority and
> responsibility to define and prioritize features. Without this, any
> project will almost certainly fail. XP calls this person or group
> "the customer" and strongly recommends that the developers have free
> and convenient access to them.
>
Sounds good. SE would have this body write down their current findings,
recommendations, etc.
>
> >2. Not everyone has confidence that such a person could stay in such a role
> >indefinetely.
>
> And yet, XP or not, the role must be filled.
Not completely by a person though. In the absence of a standing customer, the
requirements provide guidance for both BB test development and specifications. A
specification developed on that requirement can steer the designer. A design
provides guidance for the program and some help in WB test development.
Note that things often flow in two directions: the same requirements are input to
both the blacbox test development, and the specification. When it is written down,
two copies can go to each. When the requirements are incarnate, this person gets
shared between test development, and someone who might try to map problems to
solutions, or iterate some UML diagrams and game out with CRC cards, or maybe OO
Analysis is unnecessary in maintenence progrmamming, and XP?
If an analysis is not written down and copied for both WhiteBox test design, and SW
design, how do we know the same one is the basis for both?
>
>
> >3. Not everyone (maybe just Chrysler) can afford a multi-man-year, multi-person
> >software experiment, to just see if some process can work despite the wisdom of
> >experience and multiple indications that the process could not succeed.
>
> Most companies are seeing massive failures of projects as a regular
> event.
That is why software engineering has become attractive.
> Many are quite willing to risk new and unproven practices and
> processes simply because it would be hard to do worse they they are
> already doing.
>
Nah, that was that dotcom stuff that crashed a few years back. Now guys want return
on investment, not BS. Something with repeatability, that uses a process, rather
than relying on a heroic customer, that is what succssful businesses want. Hype is
old.
>
> >4. Some live in a world of paper, of contracts, and written agreements. In such
> >a world, documented requirements, interface control documents, and the like
> >provide 'treaties' which endure long after the parties which negotiated them
> >have moved on. They outlast handshakes, and are maintained by the
> >organizations, and departments which agreed to them.
>
> If the negotiating parties are not succeeded by people who continue to
> champion the cause, the documents will lose their impetus and meaning.
> Lots of projects die that particular death. C3 was one of them.
>
When the documents are available, they can be changed. When they are not available,
they can not be changed. Change is good, no?
>
> XP is not anti-document. Any document you need, you produce. XP
> simply tells you not to create a document that you don't have an
> immediate and significant need for.
Sorry, but I'm not sure if you are saying that I've really misunderstood XP and that
it does have UML diagrams, and requirments are documented, etc. or, if you are saying
that in your experience, all of your source code is self documenting, and that other
stuff, like requirements, is useless drivel. Please do tell, in general, do you find
a software requirements document to be useful, even in the form of use cases? How
about high level class diagrams? State diagrams? Activity diagrams? CRC Cards?
Detailed UML class diagrams? What about entity-relationship diagrams? I understand
that not every project is a nail, and an RDBMS might not need OO, but that doesn't
make the tools all useless. If you do find these documents to be potentially useful,
what distinguishes XP from process oriented SW development? Do other XP advocates
also encourage development of these artifiacts?
Bill Turner
Engineers gather and document requirements, validate them and review them with
customers. They develop designs and prototypes, which are also evaluated to
determine how well they meet requirements. These are fairly fundamental
activities when building a new thing. Since XP shuns such activities, is XP
engineering? It seems not. That does not mean it does not have its place, it
just isn't engineering. It is a craft based approach.
Bill
Bill Turner
David B Lightstone wrote:
> "Bill Turner" <51004898135...@t-online.de> wrote in message
> news:3D655C36...@t-online.de...
> > David,
> >
> > David B Lightstone wrote:
> >
> > > > It seems clear that the reasons for the increase in productivity is
> > > unclear.
> > >
> > > Claimed increase in productivity!!!!!! For all I know the increase may
> just
> > > be a matter of preception, a problem of observation related to the
> nature
> > > of the experiement. Possibily equivalent to the discovery of cold
> fusioon
> >
> > It was too early in the morning when I wrote the above. I was trying to
> say
> > "claimed increase". I do agree that it could be self-delusion.
>
> Bill,
>
> I make the same sort of mistakes. It is one of the things which comes with
> being a human being.
>
> Perhaps I was over reacting, but there is a phenomena about which I suspect
> many fall victim.
No offense taken.
>
>
> If you hear an erroneous claim often enough, you eventually suspend
> critical judgement, and repeat it. It is an interesting tool used in
> marketing and political rhetoric. This for purposes both of spinning things
> and misdirecting.
Robert Cialdini has written some books on this, such as "Influence: The
Psychology of Persuasion". If I recall properly, repetition is one of the
principle forms of influence. Symbols of authority is, also, such as book
authors ;-). You can see several influence factors at work in many arguments.
People seem to have an innate knowledge of these things and use them
unknowingly. Those that do understand them are much more capable of
manipulating others. One needs to be ever vigilant. Knowing these principles,
and using critical thinking, are essential to clear thinking, which is not easy
when you keep hearing about how wonderful something is. It is easy to start
questioning your own judgment.
Bill
Bill Turner
Ron Jeffries wrote:
> On Fri, 23 Aug 2002 00:15:55 +0200, Bill Turner
> <51004898135...@t-online.de> wrote:
>
> >> >I definitely want to see more research in this area. I guess I like hard evidence.
> >> >Until then, the pair programming controversy will continue.
> >>
> >> Suppose there were hard evidence saying that in a wide range of situations, PP
> >> gets the same amount of work done, compared to programming alone, and that the
> >> quality is higher. Think hard, imagine that you just read definitive research to
> >> that effect.
> >>
> >> What would you do differently from what you're doing today?
> >
> >Well, if what you are describing is a world where the vast majority of studies are
> >saying the same thing, not an almost equivalent number of studies showing opposite
> >results, then I would be committing malpractice by not pairing, or at least attempting
> >to do so.
>
> Right. I suspect that the "right" answer is "I'd try it and see if it worked for
> me."
>
> >Much has been said in this thread by people on both sides of the divide that
> >leads one to the conclusion that such a world does not exist today.
>
> I suggest that there's enough evidence to make it worth trying ... because lots
> of people are trying it. And most of them seem to be thinking it works. They
> could be on drugs, I suppose.
I have tried it. To be more precise, my team tried it at my suggestion. In fact, the whole
department attempted it. There were a couple teams that really enjoyed it. Most preferred
to not continue. Maybe we didn't work at it long enough to get it right. Certainly, like
most activities one undertakes, there is room for improvement. However, my team
specifically stuck with it the longest (over three months), and my team was split right
down the middle on its usefulness. As far as judging whether or not more work was done, it
appeared to be less was completed, nor did the code appear to assume some sort of higher
level of quality. However, not having the metrics to verify that, it is merely subjective.
By the way, at the time we were doing this, I was much more enthusiastic about XP, much
less critical. So, it wasn't my attitude that lead to the less than stellar results.
Having tried it and not being satisfied, I guess I am entitled to sit back and wait for
that hard evidence.
Bill