Chris Wheeler | 1 May 01:24 2007
Picon

Re: Words and their hidden meanings (was programming is a tiny part of the process?)

On 4/29/07, rett <rett <at> classicnet.net> wrote:
>
> Chris,
>
> And, just what is wrong with your having some hostility towards pairing.
> It is sometimes a drastically inconvenient process, and sometimes just
> not possible, no matter what is thought of it. The questions to ask then,
> are "what is XP/Agile without pairing when pairing is actually available",
> and "how is XP/Agile formed when there is only a lone developer".

Absolutely nothing wrong with feeling hostility towards a practice, all
emotions being valid. It's just that I feel no hostility towards pairing.
But out of this, you've asked two great questions that will lead somewhere,
I'm certain, had I more time to get into it right now.

Chris.

[Non-text portions of this message have been removed]

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Matt Heusser | 1 May 02:02 2007
Picon

Worse is Better

A few hours ago I posted that XP succeeded over Formal Methods because XP
subscribed to a worse-is-better philosophy:

http://www.jwz.org/doc/worse-is-better.html<http://www.jwz.org/doc/worse-is-better.html>

The response was ... mixed.  One person thought that the wording was too
controversial; another thought that the application was unclear.

I'm going to try again.

The metaphor isn't perfect, but Worse is Better is, essentially, YAGNI.  The
idea is to create working software and improve it incrementally, instead of
creating the diamond-like-jewel - the "perfect" software that is always six
months away.

From this month's ACM Queue, Pg. 18:
"Hal Stern:...If you look at the way that software is being developed now or
that services are being deployed on a network, you will see that they're
evolving rapidly.  You do something, it works, and then you find-tune it a
little bit, or people find a new way of using it.  Then you evolve from
there.  The very small footprint standards are going to be the most useful,
and they're undoubtedly going to evolve much more in public and by people
using them and trying to come up with practical applications.  There's a lot
more applied engineering than with theoretical, almost formal language
design type of thing that would normally go into developing a standard."

 --> Sorry, it does not seem to be on the web yet.

In addition, I agree, the people that developed XP are do-ers, who, well, do
stuff, and the people who developed formal methods are, well, theorists.
(Continue reading)

John Roth | 1 May 02:09 2007
Picon

Re: Words and their hidden meanings (was programming is a tiny part of the process?)

That's actually two different situations: pairing and
spending time with the people doing the work. The
latter practice is highly recommended in Lean, for
example, where there's a recognition that the actual
work of the company takes place on the 'gemba'
(I may have misspelled the transliteration from the
Japanese), not in the executive, managerial or
professional offices.

This is the first step that a Lean consultant will do:
walk out of the conference room where everyone
has assembled and into one of the work areas; then
follow the value chain. The usual result if it's done
right is, um, rather startling as reality begins to filter
through the executive preconceptions of what's going
on.

Pairing is a practice that has (IIRC) at least five
different benefits. If you can't pair, then you need to
find somewhere else in the process to put those
benefits.

John Roth

----- Original Message ----- 
From: "rett" <rett <at> classicnet.net>
To: <extremeprogramming <at> yahoogroups.com>
Sent: Sunday, April 29, 2007 4:20 PM
Subject: Re: Words and their hidden meanings (was [XP] programming is a tiny 
part of the process?)
(Continue reading)

Kent Beck | 1 May 03:08 2007

RE: Prime Directive and the energy to change (was: A Real-World Experiment With Hours Instead of Points)

George,

Your message is a good example of what I think is wrong with the "prime
directive"--because you have to pretend that I've done my best, when you say
I'm wrong you have to do so elliptically instead of being able to come out
and say it. That extra layer of pretending wastes energy and blurs
information.

I believe that you and I agree about the purpose of the "prime
directive"--to make other people responsible for my feelings and me
responsible for theirs. Where we seem to disagree is whether this is an
effective communication strategy. I don't think it is.

Regards,

Kent Beck
Three Rivers Institute

P. S. I have never seen the words "with respect" used respectfully. In this
case you seem to me that you don't respect my understanding.

  _____  

From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of George Dinwiddie
Sent: Friday, April 27, 2007 7:41 AM
To: extremeprogramming <at> yahoogroups.com
Subject: [XP] Prime Directive and the energy to change (was: A Real-World
Experiment With Hours Instead of Points)

(Continue reading)

Kent Beck | 1 May 03:17 2007

RE: A Real-World Experiment With Hours Instead of Points -- was Re: Re: Beefing up The Project Velocity

Manuel,

You and William's replies have in common the use of points as a way to avoid
bad feelings. In my life, the more I deal with reality, confronting
irrational emotions when they arise, the better my life goes. I don't like
this, in fact I hate it (another one of those irrational emotions, since it
helps my life go better), but it's clear. If I feel bad delivering 1.8 days
of work in a week, perhaps I really could deliver more by improving my work
habits, in which case I should improve my work habits, or maybe my feelings
aren't aligned with reality, in which case I should get over my bad
feelings. Or there are probably other options, since binary thinking is
another one of those warning signs for me that I'm not using my whole brain.

Regards,

Kent Beck
Three Rivers Institute

  _____  

From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of Manuel Klimek
Sent: Thursday, April 26, 2007 12:44 AM
To: extremeprogramming <at> yahoogroups.com
Subject: Re: A Real-World Experiment With Hours Instead of Points -- was Re:
[XP] Re: Beefing up The Project Velocity

Kent,

thank you for the feedback. With regards to "feeling": I find it hard
(Continue reading)

Kent Beck | 1 May 03:20 2007

RE: Adopting XP - Whole Team

Robert,

I suspect that your uncertainty comes from a certain amount of ambiguity in
the definition of "team". In talking about Whole Team, I meant the people
"in the room", those that have to interact every day (I use quotes because
of the large number of people, myself included, who aren't physically
together when they develop together). The specific counter-example that led
to this practice is the common counter-practice of having a database
administration team who only sees to the integrity of the corporation's
data. If requests for schema changes take unpredictable weeks to come
through, incremental development can be severely affected. This leads to
more speculation about the database changes that are needed, which leads to
more changes, larger changes, more risky changes. Instead, while still
taking responsible care of the corporate data, someone on the team should be
able to make the needed database changes.

"Team" can also be used at larger scales (the division, the company, the
company and its customers and its suppliers). XP has little to say about the
larger scales until you get to the advanced practices, Pay-per-use in
particular. It has not been extended to cover all of Ottawa  yet :-) 

Regards,

Kent Beck
Three Rivers Institute
Go Sharks

  _____  

From: extremeprogramming <at> yahoogroups.com
(Continue reading)

Ryan Cooper | 1 May 03:47 2007
Picon

Re: !PP == Hacking?

Hi Alain;

Sometimes I think a lot of recurring debates on forums like this one would
be resolved if we had a consise English term for "almost equals".

The problem with absolute statements is that the are -- almost ;) -- never
true. The problem with phrases like "often" or "usually" is that they are so
vague as to be completely meaningless. "Often" might mean 60% or 99%.

Using "often" may lull us into a false sense of agreement, even though one
of us means 60% and the other means 99%. Using "always" may lull us into a
false sense of major disagreement, even though one of us means 99% and the
other means 100% -- which frankly, are close enough not to matter 99% of the
time ;). So neither truly satisfactory.

Either way, as I think you suggested, it may be more worthwhile discussing
particular techniques for advocating a practice in a resistant environment,
or discussing contexts in which a practice is more/less valuable. Maybe I
just need to learn not to get sucked into a thread and read every post even
after I realize it's not my cup of tea, and let those who find it useful
continue the debate...

Cheers,
Ryan

On 4/23/07, Desilets, Alain <alain.desilets <at> nrc-cnrc.gc.ca> wrote:

> If you want to soften your assertion to something like this:
>
> "The absence of Pair Programming and Peer Review OFTEN RESULTS IN
(Continue reading)

Ron Jeffries | 1 May 04:29 2007

Re: Success of XP over Formal Methods

Hello, Matt.  On Monday, April 30, 2007, at 8:22:00 AM, you wrote:

> http://www.jwz.org/doc/worse-is-better.html

> ----> I quite seriously believe that worse-is-better should be considered
> part of the Software Development Foundation Literature, right up there with
> No Silver Bullets, Learn to Program in Ten Years, Why Does Software Cost So
> Much, Cargo-Cult Software Engineering, and PeopleWare.  If you haven't read
> it, I urge you to consider it.

Dick Gabriel is a wonderful and brilliant man. His views of the
universe are far darker than mine, however.

I do not fully agree with what Worse is Better seems to imply,
despite that it is historically accurate.

Maybe it's just that I don't want to believe.

Ron Jeffries
www.XProgramming.com
Adapt, improvise, overcome. 
  --Gunnery Sergeant Tom Highway (Heartbreak Ridge)

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Ron Jeffries | 1 May 04:38 2007

Re: Re: Do it by the book

Hello, Steve.  On Monday, April 30, 2007, at 1:49:30 PM, you wrote:

> I think you have a good point.  Most of the resistance I have seen has been
> more around the honest belief that such a set of practices just won't work.
> Especially the more experienced programmers.  There is a certain sense of
> "been there, done that, didn't work" that gets in the way of trying the new
> thing.

That really confuses me, unless they don't know what the practices
really are. The things we teach are the things that have always
worked.

Ron Jeffries
www.XProgramming.com
I once had a coworker who worked so hard that when I came in the
morning, he was already sitting there trying to fix the things he
broke after I left the day before ... -- Ilja Preuss.

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Ron Jeffries | 1 May 04:42 2007

Re: Words and their hidden meanings (was programming is a tiny part of the process?)

Hello, Steve.  On Monday, April 30, 2007, at 2:26:39 PM, you wrote:

> AFAIK, that's true. Actually, my guess is that a large majority of
> all successful software is written without XP-style pairing.

So would I. Which implies little or nothing about whether pairing
would make things better. (Nor did you suggest otherwise, of
course.)

Ron Jeffries
www.XProgramming.com
Example isn't another way to teach, it is the only way to teach.
  --Albert Einstein

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 

Gmane