Discussion:
Are You Getting XPed On
Kent Beck
2002-08-20 17:08:08 UTC
Permalink
Here is a discussion I had with the guy I had in mind while I was
writing the XPd on paper. I'm working on a new draft. In the meantime, I
would be interested in experiences folks have had trying to apply the
criteria in the first draft.

Kent

-----Original Message-----
From: ***@sabre.com [mailto:***@sabre.com]
Sent: Sunday, August 18, 2002 2:10 PM
To: Kent Beck
Subject: RE: Are You Getting XPed On



No problem forwarding the exchange.

I think I now know what you mean about people getting XPed on. I didn't
get it at first, partly because I do think that the tone of the article
is too emotional, and you may be taking it a bit personal. In every
organization, when there is either a reorganization or a major change,
people behave poorly and defensively until they figure out what it means
for them. They all figure it out at different times, which makes for
lots of dynamics over a period of time.

When I introduced XP to a business division of 600 people (300
developers) it was a huge cultural shock. It is true that some of my
developers tended to use XP as a shield. A very few tried to use it as
an excuse to disavow their responsibility to make projects come in on
time and on budget. Some used it an excuse for not making progress when
they did not get good user stories. A few created inflated estimates, a
few refused to work any overtime, etc. This was a minority of the
population, but they caused disproportionate ill will until they got it
figured out.

I think that rather than coming out and chastising developers for being
power grabbers, you could take a high road and simply explain that this
is a possible behavior that some developers will be tempted to adopt,
and that management should watch out for it. You could then describe
the signs that XP is being abused, as well as the signs that should
indicate whether people are really doing XP.

That makes me think, the signs that people are really doing XP don't
really guarantee that they are not abusing XP and grabbing too much
power. These are really two separate behaviors, and managers should
watch out for both. They have different symptoms.

As for the control of the environment, by all means take a wrench to the
desk and remove those drawers so someone can sit next to you
comfortably. Move into an underused conference room without asking
permission. Do all that, but don't expect management to knock down the
cube walls and put in the right environment for a full team unless you
have some committed, senior backing.

Brad J. (P.S. attached are my notes from the "lessons learned" panel I
was on at XPAU)



-----Original Message-----
From: Kent Beck [mailto:***@threeriversinstitute.org]
Sent: Saturday, August 17, 2002 9:01 AM
To: Jensen, Brad
Subject: RE: Are You Getting XPd On


I had heard stories about this sort of power grab before, but here I was
at this conference face to face with four very upset people who felt
disempowered by XP, and from four different teams. I felt personally
embarrassed (although that's not a very adult reaction), which probably
accounts for the too-emotional tone still in the paper.

I'm going to soften the comment about the work environment, but not
eliminate it. If all you can do is move your computer out of the corner
so you can pair, you should do that. And no one has gotten fired so far
for taking an Allen wrench to communication barriers, although I can
imagine it could happen.

Kent
P.S. Do you mind if I forward our exchange to the XP mailing list?

-----Original Message-----
From: ***@sabre.com [mailto:***@sabre.com]
Sent: Friday, August 16, 2002 5:05 PM
To: Kent Beck
Subject: RE: Are You Getting XPd On



Kent,
Where are you seeing this "programmer's power grab"? This has not
happened in my team. The only "abuse" of XP has been that the
programmer's intitially said: "We won't code without the stories, and we
won't help you write the stories". I came down hard on them and got
them to change it to "We will help you write the stories. We will even
write them for you if you sign off on them. Otherwise, we can not be
held accountable for whether the functionality is what you wanted."

I'm curious to know what got you off on this tear. Brad J.

-----Original Message-----
From: Kent Beck [mailto:***@threeriversinstitute.org]
Sent: Friday, August 16, 2002 1:29 PM
To: Jensen, Brad
Subject: RE: Are You Getting XPd On


Thanks. That's exactly the feedback I was looking for. I'm pretty upset
about the situation, so I want to be very sure that I don't negatively
dump emotions in the paper. I'll send another draft in a few days.

3: I thought was covered in Planning XP under "Big Stories". I'll look
again.

Kent

-----Original Message-----
From: ***@sabre.com [mailto:***@sabre.com]
Sent: Friday, August 16, 2002 8:03 AM
To: Kent Beck; Lowell Lindstrom; Xp Leadership
Subject: RE: Are You Getting XPd On



Kent,
This was a good article. My comments are:
1: I don't know where you plan to publish it, but I would not use the
word "shit".
2: Shared workspace. It is a little unfair to XP teams to say that
they do not understand "the extent of their authority and responsibility
for their environment." In typical companies, no XP team can change
their physical environment. It takes intervention from a very senior
manager who will fight a good fight for open space. Unless the team is
very lucky, this is not under their control.
3: Visible quarterly plan. Great stuff, but outside the definition of
what you originally defined as XP. I know that the spirit of XP is to
evolve, and AFTER A TEAM HAS REALLY BECOME PROFICIENT IN THE 12 XP
PRINCIPLES, then they should start evolving and improving. You are
trying to get the whole world to understand XP. You need to hold it
still long enough for everyone to get the idea before you start adding
new practices and portray them as things that expose "fake XPers". I
liked the article and I appreciate the last paragraph written just as
is. Thanks, Brad J.

-----Original Message-----
From: Kent Beck [mailto:***@threeriversinstitute.org]
Sent: Wednesday, August 14, 2002 12:17 AM
To: Lowell Lindstrom; Jensen, Brad; Xp Leadership
Subject: Are You Getting XPd On


Here's the paper I mentioned. I'd love feedback on any aspect of it--
more questions/things to look for, tone, intervention advice at the end.

Kent







To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kucera, Rich
2002-08-20 18:29:02 UTC
Permalink
aww man...I already saved it as shit.pdf

-----Original Message-----
From: Kent Beck [mailto:***@csi.com]
Sent: Tuesday, August 20, 2002 1:08 PM
To: ***@yahoogroups.com
Subject: [XP] FW: Are You Getting XPed On


Here is a discussion I had with the guy I had in mind while I was
writing the XPd on paper. I'm working on a new draft. In the meantime, I
would be interested in experiences folks have had trying to apply the
criteria in the first draft.

Kent

[...]

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-20 20:38:16 UTC
Permalink
Post by Kent Beck
Here is a discussion I had with the guy I had in mind while I was
writing the XPd on paper. I'm working on a new draft. In the meantime, I
would be interested in experiences folks have had trying to apply the
criteria in the first draft.
Seems to me that there are organization smells (I hate the term even
more there than in "code smells" but I know it'll communicate). The
original article blames prople and assigns motivations. Even if it's
correct, and it might be, it probably doesn't help. (I say this from
long and broad experience.)

So can the thing address
a) best: detectable things that are going wrong, or
b) better: feelings people have, and not
c) down there somewhere: bad behaviors of individuals, and then

go right on to what the people who detect the things, or who feel bad,
can /do/ to make it better.

Example:

Feeling uncertain about the quality of the system? Define more
Acceptance Tests, and schedule them for implementation in the next
iteration. Stop scheduling new features until you're comfortable
with the existing ones.

Maybe it's a patterns paper ...

Ron Jeffries
www.XProgramming.com
I have tried in my way to be free. -- Leonard Cohen


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-21 13:44:51 UTC
Permalink
Post by Ron Jeffries
Post by Kent Beck
Here is a discussion I had with the guy I had in mind while I was
writing the XPd on paper. I'm working on a new draft. In the meantime, I
would be interested in experiences folks have had trying to apply the
criteria in the first draft.
Seems to me that there are organization smells (I hate the term even
more there than in "code smells" but I know it'll communicate). The
original article blames prople and assigns motivations. Even if it's
correct, and it might be, it probably doesn't help. (I say this from
long and broad experience.)
Identifying people that you need to get through to is helpful. Blaming them isn't. Likewise, what little experiance I have with professional counseling tells me that assigning motivations is worse than useless - you're almost always wrong, even if the motivation told you something useful to do about the situation. Which it won't, most of the time.
Post by Ron Jeffries
So can the thing address
a) best: detectable things that are going wrong, or
b) better: feelings people have, and not
c) down there somewhere: bad behaviors of individuals, and then
go right on to what the people who detect the things, or who feel bad,
can /do/ to make it better.
Feeling uncertain about the quality of the system? Define more
Acceptance Tests, and schedule them for implementation in the next
iteration. Stop scheduling new features until you're comfortable
with the existing ones.
Maybe it's a patterns paper ...
There are two things I can suggest.

1. Get some serious sales training. Much of the useful stuff I know came from a used car salesman. Like: "Once you've given the closer, keep your g-d d-d mouth shut! You lose more sales talking while the guy is trying to think."

2. Ask what the person would need to feel more comfortable (or whatever his language suggests would be a better word than comfortable.) The odds are, he'll tell you. You don't have to guess.

John Roth
Post by Ron Jeffries
Ron Jeffries
www.XProgramming.com
I have tried in my way to be free. -- Leonard Cohen
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Christopher Hart
2002-08-20 23:25:04 UTC
Permalink
Kent,

Balance of Power? What is this...some kind of Euro-dominance thing from the
1800s? Everyone needs to think Teamwork and Cooperation and Communication.
Are the customers and developers operating as a team, or is this an us vs.
them mentality? If XP is being used as shield by anyone they clearly don't
get it or they are too afraid of committing to XP.

The examples also bring forward one of the failings in communicating XP in
that it is still too developer-centric. Business types are not being engaged
in these ideas in an equal portion. And since they aren't getting exposed to
XP, they can't effectively prevent certain developer power abusers from
creating shields. The customer is largely being excluded from the team so
that ivory-tower developers in white lab coats can take us back decades.
Ick.

The paradigm shift to XP is painful for both developers and customers
because it requires trust. However it also provides the mechanisms to build
trust. Unfortunately some people are using the name XP to disolve trust.
Again ick.

Best Regards,

Chris Hart

----- Original Message -----
From: "Kent Beck" <***@csi.com>
To: <***@yahoogroups.com>
Sent: Tuesday, August 20, 2002 11:08 AM
Subject: [XP] FW: Are You Getting XPed On
Post by Kent Beck
Here is a discussion I had with the guy I had in mind while I was
writing the XPd on paper. I'm working on a new draft. In the meantime, I
would be interested in experiences folks have had trying to apply the
criteria in the first draft.
Kent
-----Original Message-----
Sent: Sunday, August 18, 2002 2:10 PM
To: Kent Beck
Subject: RE: Are You Getting XPed On
No problem forwarding the exchange.
I think I now know what you mean about people getting XPed on. I didn't
get it at first, partly because I do think that the tone of the article
is too emotional, and you may be taking it a bit personal. In every
organization, when there is either a reorganization or a major change,
people behave poorly and defensively until they figure out what it means
for them. They all figure it out at different times, which makes for
lots of dynamics over a period of time.
When I introduced XP to a business division of 600 people (300
developers) it was a huge cultural shock. It is true that some of my
developers tended to use XP as a shield. A very few tried to use it as
an excuse to disavow their responsibility to make projects come in on
time and on budget. Some used it an excuse for not making progress when
they did not get good user stories. A few created inflated estimates, a
few refused to work any overtime, etc. This was a minority of the
population, but they caused disproportionate ill will until they got it
figured out.
I think that rather than coming out and chastising developers for being
power grabbers, you could take a high road and simply explain that this
is a possible behavior that some developers will be tempted to adopt,
and that management should watch out for it. You could then describe
the signs that XP is being abused, as well as the signs that should
indicate whether people are really doing XP.
That makes me think, the signs that people are really doing XP don't
really guarantee that they are not abusing XP and grabbing too much
power. These are really two separate behaviors, and managers should
watch out for both. They have different symptoms.
As for the control of the environment, by all means take a wrench to the
desk and remove those drawers so someone can sit next to you
comfortably. Move into an underused conference room without asking
permission. Do all that, but don't expect management to knock down the
cube walls and put in the right environment for a full team unless you
have some committed, senior backing.
Brad J. (P.S. attached are my notes from the "lessons learned" panel I
was on at XPAU)
-----Original Message-----
Sent: Saturday, August 17, 2002 9:01 AM
To: Jensen, Brad
Subject: RE: Are You Getting XPd On
I had heard stories about this sort of power grab before, but here I was
at this conference face to face with four very upset people who felt
disempowered by XP, and from four different teams. I felt personally
embarrassed (although that's not a very adult reaction), which probably
accounts for the too-emotional tone still in the paper.
I'm going to soften the comment about the work environment, but not
eliminate it. If all you can do is move your computer out of the corner
so you can pair, you should do that. And no one has gotten fired so far
for taking an Allen wrench to communication barriers, although I can
imagine it could happen.
Kent
P.S. Do you mind if I forward our exchange to the XP mailing list?
-----Original Message-----
Sent: Friday, August 16, 2002 5:05 PM
To: Kent Beck
Subject: RE: Are You Getting XPd On
Kent,
Where are you seeing this "programmer's power grab"? This has not
happened in my team. The only "abuse" of XP has been that the
programmer's intitially said: "We won't code without the stories, and we
won't help you write the stories". I came down hard on them and got
them to change it to "We will help you write the stories. We will even
write them for you if you sign off on them. Otherwise, we can not be
held accountable for whether the functionality is what you wanted."
I'm curious to know what got you off on this tear. Brad J.
-----Original Message-----
Sent: Friday, August 16, 2002 1:29 PM
To: Jensen, Brad
Subject: RE: Are You Getting XPd On
Thanks. That's exactly the feedback I was looking for. I'm pretty upset
about the situation, so I want to be very sure that I don't negatively
dump emotions in the paper. I'll send another draft in a few days.
3: I thought was covered in Planning XP under "Big Stories". I'll look
again.
Kent
-----Original Message-----
Sent: Friday, August 16, 2002 8:03 AM
To: Kent Beck; Lowell Lindstrom; Xp Leadership
Subject: RE: Are You Getting XPd On
Kent,
1: I don't know where you plan to publish it, but I would not use the
word "shit".
2: Shared workspace. It is a little unfair to XP teams to say that
they do not understand "the extent of their authority and responsibility
for their environment." In typical companies, no XP team can change
their physical environment. It takes intervention from a very senior
manager who will fight a good fight for open space. Unless the team is
very lucky, this is not under their control.
3: Visible quarterly plan. Great stuff, but outside the definition of
what you originally defined as XP. I know that the spirit of XP is to
evolve, and AFTER A TEAM HAS REALLY BECOME PROFICIENT IN THE 12 XP
PRINCIPLES, then they should start evolving and improving. You are
trying to get the whole world to understand XP. You need to hold it
still long enough for everyone to get the idea before you start adding
new practices and portray them as things that expose "fake XPers". I
liked the article and I appreciate the last paragraph written just as
is. Thanks, Brad J.
-----Original Message-----
Sent: Wednesday, August 14, 2002 12:17 AM
To: Lowell Lindstrom; Jensen, Brad; Xp Leadership
Subject: Are You Getting XPd On
Here's the paper I mentioned. I'd love feedback on any aspect of it--
more questions/things to look for, tone, intervention advice at the end.
Kent
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
kentlbeck
2002-08-21 01:38:31 UTC
Permalink
Post by Christopher Hart
Kent,
Balance of Power? What is this...some kind of Euro-dominance thing from the
1800s? Everyone needs to think Teamwork and Cooperation and
Communication.
Post by Christopher Hart
Are the customers and developers operating as a team, or is this an us vs.
them mentality? If XP is being used as shield by anyone they
clearly don't
Post by Christopher Hart
get it or they are too afraid of committing to XP.
The examples also bring forward one of the failings in
communicating XP in
Post by Christopher Hart
that it is still too developer-centric. Business types are not
being engaged
Post by Christopher Hart
in these ideas in an equal portion. And since they aren't getting exposed to
XP, they can't effectively prevent certain developer power abusers from
creating shields. The customer is largely being excluded from the team so
that ivory-tower developers in white lab coats can take us back decades.
Ick.
The paradigm shift to XP is painful for both developers and
customers
Post by Christopher Hart
because it requires trust. However it also provides the mechanisms to build
trust. Unfortunately some people are using the name XP to disolve trust.
Again ick.
Best Regards,
Chris Hart
Thank you, Chris. Could you suggest one small thing I could change
about the paper so it would (better) address the issues you raise
above?

Kent


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Christopher Hart
2002-08-21 14:52:25 UTC
Permalink
Kent,

OK. The balance of power idea is dangerous traditional thinking. It assumes
that the relationship between the developers and customers is a zero-sum
game of I win, you lose. As such it indicates that a power struggle between
the two halves of the "team" is normal. What we in the XP community should
be doing is breaking down the power structures and building trust. Also the
word "dictates", while it fits in with the balance of power scenario, takes
us away from cooperation. In other words "I tell you what to do here and you
have to go along." Ugly word. If the purpose of the BOP section is to point
out what is happening in the real world of XP-as-buzzword, that needs to be
more clear. "...intended to create a balance of power" sends the wrong
message.

What the testers in the example need to do is engage the business side. When
a manager or executive starts asking the developers about planning meetings,
the warroom environment, and how many onsite customers they need, the
developers are not going to be able to use a buzzword shield. One XP-savvy
onsite customer gives the customer all the oversite they need. Somebody
needs to sell the customers on the value they get out of XP and then get
them involved. Until the customer knows what they are supposed to be getting
out of XP, they will lack the context to do any more than know they are
being lied to by the buzzword crowd.

Is that helpful?

Best Regards,

Chris

----- Original Message -----
From: "kentlbeck" <***@csi.com>
To: <***@yahoogroups.com>
Sent: Tuesday, August 20, 2002 7:38 PM
Subject: Re: [XP] FW: Are You Getting XPed On
Post by Kent Beck
Post by Christopher Hart
Kent,
Balance of Power? What is this...some kind of Euro-dominance thing
from the
Post by Christopher Hart
1800s? Everyone needs to think Teamwork and Cooperation and
Communication.
Post by Christopher Hart
Are the customers and developers operating as a team, or is this
an us vs.
Post by Christopher Hart
them mentality? If XP is being used as shield by anyone they
clearly don't
Post by Christopher Hart
get it or they are too afraid of committing to XP.
The examples also bring forward one of the failings in
communicating XP in
Post by Christopher Hart
that it is still too developer-centric. Business types are not
being engaged
Post by Christopher Hart
in these ideas in an equal portion. And since they aren't getting
exposed to
Post by Christopher Hart
XP, they can't effectively prevent certain developer power abusers
from
Post by Christopher Hart
creating shields. The customer is largely being excluded from the
team so
Post by Christopher Hart
that ivory-tower developers in white lab coats can take us back
decades.
Post by Christopher Hart
Ick.
The paradigm shift to XP is painful for both developers and
customers
Post by Christopher Hart
because it requires trust. However it also provides the mechanisms
to build
Post by Christopher Hart
trust. Unfortunately some people are using the name XP to disolve
trust.
Post by Christopher Hart
Again ick.
Best Regards,
Chris Hart
Thank you, Chris. Could you suggest one small thing I could change
about the paper so it would (better) address the issues you raise
above?
Kent
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dhemeryy
2002-08-21 18:57:56 UTC
Permalink
Hi Kent,
Post by kentlbeck
Thank you, Chris. Could you suggest one small thing I could change
about the paper so it would (better) address the issues you raise
above?
Though I'm not Chris, I do have a suggestion. I liked the article
when I read it initially. When I reread it in light of this thread, I
felt a twinge when I read: "here are things to look for and questions
to ask that should make fake Xpers squirm in their seats." That
reenforces the divisiveness that I think you're trying to heal.

Consider something like, "here are things to look for and questions to
ask that can nudge your whole team toward the cooperative,
collaborative attitude that makes an effective XP team shine."

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kay A. Pentecost
2002-08-21 19:57:03 UTC
Permalink
Hi, Dale,

This is nice.

Kay
Post by Kent Beck
-----Original Message-----
Sent: Wednesday, August 21, 2002 2:58 PM
Subject: Re: [XP] FW: Are You Getting XPed On
Hi Kent,
Post by kentlbeck
Thank you, Chris. Could you suggest one small thing I could change
about the paper so it would (better) address the issues you raise
above?
Though I'm not Chris, I do have a suggestion. I liked the article
<snip>
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
C. Keith Ray
2002-08-26 00:27:17 UTC
Permalink
Kent and Alistair seem to have the same concern...

<http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming>

I actually am concerned that XP is about to become the new
AnAcceptableWayOfFailing because people won't do what it says to do, but do
whatever they used to do, and excuse it by calling it XP. Thereby giving a
bad name to a whole slew of light practices. Therefore, I want a special
moniker to brand them with, to be able to say, "That's not XP; that's PAP."
or whatever the most demoralizing nickname we can come up with to denote the
really not XP practice set. I hope in this way to protect the value of the
XP name and practice set. --AlistairCockburn

----

C. Keith Ray
<http://homepage.mac.com/keithray/resume2.html>
<http://homepage.mac.com/keithray/xpminifaq.html>



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Brad Appleton
2002-08-26 03:08:51 UTC
Permalink
Post by C. Keith Ray
Kent and Alistair seem to have the same concern...
<http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming>
I actually am concerned that XP is about to become the new
AnAcceptableWayOfFailing because people won't do what it
says to do, but do whatever they used to do, and excuse
it by calling it XP
At the same time, I'm sure there are also many folks out there making a legitimate effort to attempt to do XP, but can't necessarily do all the practices and/or with adaptation. One can argue whether or not its fair to call them "not XP" or whatever the "demoralizing nickname" is that gets devised.

This sort of thing is why some folks decide to have their "thing" require some kind of licensing or certification - so that others can't formally claim to "have it" or be "doing it" without the official "my thing" seal of approval.

I'd be surprised if Kent and/or Ron really wanted to get into the business of "certifying" XP (both can feel free to correct me if I'm mistaken :-). It would "smack" too much of the kind of CMM-style rubber-stamping that many in the agile community find loathsome.

At the same time, is there some clear "XP Litmus Test" that can be applied that might help discern not only if one is doing "pure XP", but also help discern if they are making a legitimately feasible attempt and not trying to ex-pee on anyone?
--
Brad Appleton <***@bradapp.net> http://www.bradapp.net/
"Education is the ability to listen to almost anything
without losing your temper or your self-confidence."
-- Robert Frost

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-26 08:11:25 UTC
Permalink
Post by Brad Appleton
Post by C. Keith Ray
Kent and Alistair seem to have the same concern...
<http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming>
I actually am concerned that XP is about to become the new
AnAcceptableWayOfFailing because people won't do what it
says to do, but do whatever they used to do, and excuse
it by calling it XP
At the same time, I'm sure there are also many folks out there
making a legitimate effort to attempt to do XP, but can't
necessarily do all the practices and/or with adaptation. One can
argue whether or not its fair to call them "not XP" or whatever the
"demoralizing nickname" is that gets devised.
Yes. I asked Kent at XPU what XP was, because I've always wondered. He
told me that XP is a community of software development practice based
on values of simplicity, communication, feedback, and courage.

I asked myself what XP is, before my keynote, and decided that XP is
what you know after you have done all the practices, all the time,
long enough.
Post by Brad Appleton
This sort of thing is why some folks decide to have their "thing"
require some kind of licensing or certification - so that others
can't formally claim to "have it" or be "doing it" without the
official "my thing" seal of approval.
I'd be surprised if Kent and/or Ron really wanted to get into the
business of "certifying" XP (both can feel free to correct me if I'm
mistaken :-). It would "smack" too much of the kind of CMM-style
rubber-stamping that many in the agile community find loathsome.
Kent has, in the past, made clear that XP certification is anathema. I
suspect there are days, like the day he wrote "Are you getting XPed
On", when he feels otherwise.
Post by Brad Appleton
At the same time, is there some clear "XP Litmus Test" that can be
applied that might help discern not only if one is doing "pure XP",
but also help discern if they are making a legitimately feasible
attempt and not trying to ex-pee on anyone?
I'm honestly not sure. I feel sure that any actual member of the
community Kent names, or anyone who has done the practices fully,
could visit a project that was trying to do XP, or was claiming to do
XP, and find things they could do that would increase simplicity,
communication, feedback, and courage. And I feel sure that they would
have at least a subjective sense of the extent to which the project
was doing as much XP as possible in the circumstances.

I share the concern that XP will be watered down, and the name
misused. I know of projects where, in my opinion, this is going on
right now. What to do? I don't know.

I rather like William Krebs' self-assessment form written up in this
year's XPU proceedings. I'd like to try something similar. It might
have the same benefits of raising a group's consciousness about what
XP is or might be for them, without the flavor of outside
certification.

Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dscxpteam
2002-08-26 12:44:41 UTC
Permalink
Post by Ron Jeffries
Post by Brad Appleton
Post by C. Keith Ray
Kent and Alistair seem to have the same concern...
<http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming>
I actually am concerned that XP is about to become the new
AnAcceptableWayOfFailing because people won't do what it
says to do, but do whatever they used to do, and excuse
it by calling it XP
At the same time, I'm sure there are also many folks out there
making a legitimate effort to attempt to do XP, but can't
necessarily do all the practices and/or with adaptation. One can
argue whether or not its fair to call them "not XP" or whatever the
"demoralizing nickname" is that gets devised.
Yes. I asked Kent at XPU what XP was, because I've always wondered. He
told me that XP is a community of software development practice based
on values of simplicity, communication, feedback, and courage.
I asked myself what XP is, before my keynote, and decided that XP is
what you know after you have done all the practices, all the time,
long enough.
Post by Brad Appleton
This sort of thing is why some folks decide to have their "thing"
require some kind of licensing or certification - so that others
can't formally claim to "have it" or be "doing it" without the
official "my thing" seal of approval.
I'd be surprised if Kent and/or Ron really wanted to get into the
business of "certifying" XP (both can feel free to correct me if I'm
mistaken :-). It would "smack" too much of the kind of CMM-style
rubber-stamping that many in the agile community find loathsome.
Kent has, in the past, made clear that XP certification is
anathema. I
Post by Ron Jeffries
suspect there are days, like the day he wrote "Are you getting XPed
On", when he feels otherwise.
Post by Brad Appleton
At the same time, is there some clear "XP Litmus Test" that can be
applied that might help discern not only if one is doing "pure XP",
but also help discern if they are making a legitimately feasible
attempt and not trying to ex-pee on anyone?
I'm honestly not sure. I feel sure that any actual member of the
community Kent names, or anyone who has done the practices fully,
could visit a project that was trying to do XP, or was claiming to do
XP, and find things they could do that would increase simplicity,
communication, feedback, and courage. And I feel sure that they would
have at least a subjective sense of the extent to which the project
was doing as much XP as possible in the circumstances.
I share the concern that XP will be watered down, and the name
misused. I know of projects where, in my opinion, this is going on
right now. What to do? I don't know.
I rather like William Krebs' self-assessment form written up in this
year's XPU proceedings. I'd like to try something similar. It might
have the same benefits of raising a group's consciousness about what
XP is or might be for them, without the flavor of outside
certification.
Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.
The self-assessment form of Mr. Kreb's you mentioned sounds quite
interesting. Is it available anywhere that I might be able to get a
look at it? By the way, what is XPU? (I may have missed it in an
earlier posting on this thread).

Thanks.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-26 13:06:39 UTC
Permalink
Post by dscxpteam
The self-assessment form of Mr. Kreb's you mentioned sounds quite
interesting. Is it available anywhere that I might be able to get a
look at it? By the way, what is XPU?
I'm not aware of a web copy of Krebs' thing. XPU is my abbreviation
for XP / Agile Universe, a conference held earlier this year.

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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-26 22:08:22 UTC
Permalink
Post by Ron Jeffries
Post by Brad Appleton
Post by C. Keith Ray
Kent and Alistair seem to have the same concern...
<http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming>
I actually am concerned that XP is about to become the new
AnAcceptableWayOfFailing because people won't do what it
says to do, but do whatever they used to do, and excuse
it by calling it XP
At the same time, I'm sure there are also many folks out there
making a legitimate effort to attempt to do XP, but can't
necessarily do all the practices and/or with adaptation. One can
argue whether or not its fair to call them "not XP" or whatever the
"demoralizing nickname" is that gets devised.
Yes. I asked Kent at XPU what XP was, because I've always wondered. He
told me that XP is a community of software development practice based
on values of simplicity, communication, feedback, and courage.
I asked myself what XP is, before my keynote, and decided that XP is
what you know after you have done all the practices, all the time,
long enough.
Post by Brad Appleton
This sort of thing is why some folks decide to have their "thing"
require some kind of licensing or certification - so that others
can't formally claim to "have it" or be "doing it" without the
official "my thing" seal of approval.
I'd be surprised if Kent and/or Ron really wanted to get into the
business of "certifying" XP (both can feel free to correct me if I'm
mistaken :-). It would "smack" too much of the kind of CMM-style
rubber-stamping that many in the agile community find loathsome.
Kent has, in the past, made clear that XP certification is anathema. I
suspect there are days, like the day he wrote "Are you getting XPed
On", when he feels otherwise.
Post by Brad Appleton
At the same time, is there some clear "XP Litmus Test" that can be
applied that might help discern not only if one is doing "pure XP",
but also help discern if they are making a legitimately feasible
attempt and not trying to ex-pee on anyone?
I'm honestly not sure. I feel sure that any actual member of the
community Kent names, or anyone who has done the practices fully,
could visit a project that was trying to do XP, or was claiming to do
XP, and find things they could do that would increase simplicity,
communication, feedback, and courage. And I feel sure that they would
have at least a subjective sense of the extent to which the project
was doing as much XP as possible in the circumstances.
I share the concern that XP will be watered down, and the name
misused. I know of projects where, in my opinion, this is going on
right now. What to do? I don't know.
I rather like William Krebs' self-assessment form written up in this
year's XPU proceedings. I'd like to try something similar. It might
have the same benefits of raising a group's consciousness about what
XP is or might be for them, without the flavor of outside
certification.
Just to throw my log on the fire, I would say that for me, a project should be actually doing at least the following: frequent releases, automated acceptance testing, one or two week fixed length iterations, test driven development (including frequent commits to production) and shared code ownership. The rest of the practices are, without any doubt, very useful, but observation shows that they are sometimes not done by teams getting solid results.

I suspect that other people may very well have other answers.

John Roth
Post by Ron Jeffries
Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dave Rooney
2002-08-27 00:58:20 UTC
Permalink
Responding to John Roth,

[big-honking snip]
Post by jhrothjr
Just to throw my log on the fire, I would say that for me,
frequent releases, automated acceptance testing, one or two
week fixed length iterations, test driven development (including
frequent commits to production) and shared code ownership. The
rest of the practices are, without any doubt, very useful,
but observation shows that they are sometimes not done by
teams getting solid results.
[snip]

I agree in principle, but my project is living proof that frequent commits
to production aren't always feasible. It costs about $30-40K each time we
want to deploy the application to the users' desktop due to infrastructure
and roll-out testing costs. If we are only making DB changes, it's about
$8K. I actually considered storing the EXE and DLL's in the database as
BLOB's... "honest, it's just a code table update!" :)

What we are able to do is deploy to a separate user testing environment that
is controlled by my client's organization. There's no direct cost to use
it, and we can make the deployment simulate production quite closely. That
way, when it comes time to really release to production, there are no
surprises and the users have already tested to their hearts' content. It
isn't a perfect solution, but it's better than nothing.

Dave Rooney
Mayford Technologies
http://www.mayford.ca



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Brad Appleton
2002-08-27 03:26:17 UTC
Permalink
Dave,

one of the products I work on has similar issues regarding deployment and infrastructure costs (and also considered the BLOB alternative :-)

I think we use the same basic solution you described. We call it a "customer sandbox" or "sandbox system". We have a customer-accessible installation of the product that we make available to them for testing and validation. It is installed with configuration options and "business rules" that attempt to simulate their production systems as closely as possible without divulging any data they consider to be confidential or proprietary. The system includes a mechanism for them to automatically send in feedback/reports/new-requests/discrepancies (etc.)
Post by Dave Rooney
I agree in principle, but my project is living proof that frequent commits
to production aren't always feasible. It costs about $30-40K each time we
want to deploy the application to the users' desktop due to infrastructure
and roll-out testing costs. If we are only making DB changes, it's about
$8K. I actually considered storing the EXE and DLL's in the database as
BLOB's... "honest, it's just a code table update!" :)
What we are able to do is deploy to a separate user testing environment that
is controlled by my client's organization. There's no direct cost to use
it, and we can make the deployment simulate production quite closely. That
way, when it comes time to really release to production, there are no
surprises and the users have already tested to their hearts' content. It
isn't a perfect solution, but it's better than nothing.
--
Brad Appleton <***@bradapp.net> http://www.bradapp.net/
"Education is the ability to listen to almost anything
without losing your temper or your self-confidence."
-- Robert Frost

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dave Rooney
2002-08-27 09:55:12 UTC
Permalink
Brad,
Post by Brad Appleton
We call it a "customer sandbox"
My client calls it the 'Unified Acceptance Testing' environment. That
sounds much more impressive to those whose hair is pointy! :)

You know, the more I think about that BLOB idea, the more I think I should
try it! Didn't Larry Ellison say something about "the database is the
application"? Or was that Marshall McLuhan? :)

Dave Rooney
Mayford Technologies
http://www.mayford.ca


-----Original Message-----
From: Brad Appleton [mailto:***@bradapp.net]
Sent: Monday, August 26, 2002 11:26 PM
To: ***@yahoogroups.com
Subject: Re: [XP] FW: Are You Getting XPed On


Dave,

one of the products I work on has similar issues regarding deployment and
infrastructure costs (and also considered the BLOB alternative :-)

I think we use the same basic solution you described. We call it a "customer
sandbox" or "sandbox system". We have a customer-accessible installation of
the product that we make available to them for testing and validation. It is
installed with configuration options and "business rules" that attempt to
simulate their production systems as closely as possible without divulging
any data they consider to be confidential or proprietary. The system
includes a mechanism for them to automatically send in
feedback/reports/new-requests/discrepancies (etc.)
Post by Brad Appleton
I agree in principle, but my project is living proof that frequent commits
to production aren't always feasible. It costs about $30-40K each time we
want to deploy the application to the users' desktop due to infrastructure
and roll-out testing costs. If we are only making DB changes, it's about
$8K. I actually considered storing the EXE and DLL's in the database as
BLOB's... "honest, it's just a code table update!" :)
What we are able to do is deploy to a separate user testing environment that
is controlled by my client's organization. There's no direct cost to use
it, and we can make the deployment simulate production quite closely.
That
Post by Brad Appleton
way, when it comes time to really release to production, there are no
surprises and the users have already tested to their hearts' content. It
isn't a perfect solution, but it's better than nothing.
--
Brad Appleton <***@bradapp.net> http://www.bradapp.net/
"Education is the ability to listen to almost anything
without losing your temper or your self-confidence."
-- Robert Frost

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Brad Appleton
2002-08-27 21:46:58 UTC
Permalink
Post by Dave Rooney
My client calls it the 'Unified Acceptance Testing' environment. That
sounds much more impressive to those whose hair is pointy! :)
Cool!
Post by Dave Rooney
You know, the more I think about that BLOB idea, the more I think I should
try it! Didn't Larry Ellison say something about "the database is the
application"? Or was that Marshall McLuhan? :)
Interestingly enough, we have implemented something along those lines. Certain information regarding "rules logic" was previously hardcoded in the database regarding the structure and interpretation of the rules. Because deployment costs were high for new upgrades (hence making changes expensive) we found a way to encode that information in the database itself, storing it in BLOBs where it can be configured after upgrade/installation at run-time, and which won't require a software change/upgrade to change the behavior (since it is now a configuration option).
--
Brad Appleton <***@bradapp.net> http://www.bradapp.net/
"Education is the ability to listen to almost anything
without losing your temper or your self-confidence."
-- Robert Frost

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-27 13:28:58 UTC
Permalink
Post by Dave Rooney
Responding to John Roth,
[big-honking snip]
Post by jhrothjr
Just to throw my log on the fire, I would say that for me,
frequent releases, automated acceptance testing, one or two
week fixed length iterations, test driven development (including
frequent commits to production) and shared code ownership. The
rest of the practices are, without any doubt, very useful,
but observation shows that they are sometimes not done by
teams getting solid results.
[snip]
I agree in principle, but my project is living proof that frequent commits
to production aren't always feasible. It costs about $30-40K each time we
want to deploy the application to the users' desktop due to infrastructure
and roll-out testing costs. If we are only making DB changes, it's about
$8K. I actually considered storing the EXE and DLL's in the database as
BLOB's... "honest, it's just a code table update!" :)
I think we miscommunicated. "Frequent commits to production" refers to the code repository. "Frequent releases" is deployment, and that, of course, has to be at the customer's convenience.

John Roth



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dave Rooney
2002-08-27 13:48:02 UTC
Permalink
John,

Sorry, my mistake!

Dave Rooney
Mayford Technologies
http://www.mayford.ca


-----Original Message-----
From: jhrothjr [mailto:***@jhrothjr.com]
Sent: Tuesday, August 27, 2002 9:29 AM
To: ***@yahoogroups.com
Subject: Re: [XP] FW: Are You Getting XPed On
Post by Dave Rooney
Responding to John Roth,
[big-honking snip]
Post by jhrothjr
Just to throw my log on the fire, I would say that for me,
frequent releases, automated acceptance testing, one or two
week fixed length iterations, test driven development (including
frequent commits to production) and shared code ownership. The
rest of the practices are, without any doubt, very useful,
but observation shows that they are sometimes not done by
teams getting solid results.
[snip]
I agree in principle, but my project is living proof that frequent commits
to production aren't always feasible. It costs about $30-40K each time we
want to deploy the application to the users' desktop due to infrastructure
and roll-out testing costs. If we are only making DB changes, it's about
$8K. I actually considered storing the EXE and DLL's in the database as
BLOB's... "honest, it's just a code table update!" :)
I think we miscommunicated. "Frequent commits to production" refers to the
code repository. "Frequent releases" is deployment, and that, of course, has
to be at the customer's convenience.

John Roth



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kucera, Rich
2002-08-21 15:18:33 UTC
Permalink
Post by Christopher Hart
The paradigm shift to XP is painful for both developers and customers
because it requires trust. However it also provides the mechanisms to build
trust. Unfortunately some people are using the name XP to disolve trust.
Again ick.
This response is not in the context of Kent's document, but here goes:

How does XP require more trust, if you are giving the customer the value
of what they are paying for now, that is sooner, than in the old way?

Seems to me XP removes some the requirement for trust, instead of
requiring more trust.

In the old way, you'd do a BUFD, promising all this value you'd
deliver in the future. Seems to me that would require a lot of
trust on the customers part.

Again, not in the context of the power grab issue, which I don't
really get--why would developers want to get involved in that
cutthroat business--keep your freakin heads down.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Christopher Hart
2002-08-21 17:52:34 UTC
Permalink
Post by Kucera, Rich
How does XP require more trust, if you are giving the customer the value
of what they are paying for now, that is sooner, than in the old way?
Seems to me XP removes some the requirement for trust, instead of
requiring more trust.
You have pair programming, planning, the onsite customer, metaphor, the
warroom environment, a faster release schedule, and other practices all
conspiring to foster trust through full disclosure and greater
communication. Won't work without trust. One of the greatest hinderances to
the acceptance of XP is trusting the developers/customers/other
department/others long enough to show results. Once the positive results are
in then additional trust can be built. How many developers sign up for
project when the customer is free to cancel at any point becuase he feels he
has enough business value? How many developers are comfortable with other
people constantly in their code and looking over their shoulders? How many
developers are comfortable having the customer right there? How many
developers are confident in their ability to make acurate estimates two
weeks out and commit to those? How many customers feel safe doing an open
ended contract? It's too easy to get burned by the other side by being held
accountable for what you have revealed. And the deeper you get in the more
exposed you are, however you can hedge this by all the instances of
delivering value.
Post by Kucera, Rich
In the old way, you'd do a BUFD, promising all this value you'd
deliver in the future. Seems to me that would require a lot of
trust on the customers part.
There is no trust in BDUF. The developers continually complain that users,
think drug-users for the right level of contempt, don't know what they want
and have unrealistic expectations. The customers think the developers are
lying about the schedule because either they can deliver faster and are too
lazy to do so, or it's going to be late and overbudget. Plus it's not going
to work or its going to be irrelevant. Developers routinely wing the predict
ion because they rarely have enough detail on the specs. They are often
forced to come up with a feel-good number/date so that the other side goes
away and lets them get something done. BDUF has no mechanisms to build trust
either. I trust you because I have to, and hopefully I can sue if I'm not
happy.
Post by Kucera, Rich
Again, not in the context of the power grab issue, which I don't
really get--why would developers want to get involved in that
cutthroat business--keep your freakin heads down.
Developers are human and don't appreciate being walked all over. It's either
play the game or get stomped on.

Gee...I sound cynical.

Best regards,

Chris


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Steve Ropa
2002-08-21 15:19:50 UTC
Permalink
Kent, et al...

Am I right in assuming that the intended audience for this paper is indeed the business side of the organization? This would affect which language would work best. With my business-person hat on, I see no problem with phrases like balance of power. These are terms that the biz community is comfortable with. Creating/Maintaining a Balance of Power is a good thing. On a more cautionary note, many historians feel that WWI came about largely because everyone was caught up in a tremendously elaborate scheme of alliances in order to.....Create a Balance of Power....

Steve
Post by Kent Beck
-----Original Message-----
Sent: Wednesday, August 21, 2002 8:52 AM
Subject: Re: [XP] FW: Are You Getting XPed On
Kent,
OK. The balance of power idea is dangerous traditional
thinking. It assumes
that the relationship between the developers and customers is
a zero-sum
game of I win, you lose. As such it indicates that a power
struggle between
the two halves of the "team" is normal. What we in the XP
community should
be doing is breaking down the power structures and building
trust. Also the
word "dictates", while it fits in with the balance of power
scenario, takes
us away from cooperation. In other words "I tell you what to
do here and you
have to go along." Ugly word. If the purpose of the BOP
section is to point
out what is happening in the real world of XP-as-buzzword,
that needs to be
more clear. "...intended to create a balance of power" sends the wrong
message.
What the testers in the example need to do is engage the
business side. When
a manager or executive starts asking the developers about
planning meetings,
the warroom environment, and how many onsite customers they need, the
developers are not going to be able to use a buzzword shield.
One XP-savvy
onsite customer gives the customer all the oversite they
need. Somebody
needs to sell the customers on the value they get out of XP
and then get
them involved. Until the customer knows what they are
supposed to be getting
out of XP, they will lack the context to do any more than
know they are
being lied to by the buzzword crowd.
Is that helpful?
Best Regards,
Chris
----- Original Message -----
Sent: Tuesday, August 20, 2002 7:38 PM
Subject: Re: [XP] FW: Are You Getting XPed On
Post by Kent Beck
Post by Christopher Hart
Kent,
Balance of Power? What is this...some kind of Euro-dominance thing
from the
Post by Christopher Hart
1800s? Everyone needs to think Teamwork and Cooperation and
Communication.
Post by Christopher Hart
Are the customers and developers operating as a team, or is this
an us vs.
Post by Christopher Hart
them mentality? If XP is being used as shield by anyone they
clearly don't
Post by Christopher Hart
get it or they are too afraid of committing to XP.
The examples also bring forward one of the failings in
communicating XP in
Post by Christopher Hart
that it is still too developer-centric. Business types are not
being engaged
Post by Christopher Hart
in these ideas in an equal portion. And since they aren't getting
exposed to
Post by Christopher Hart
XP, they can't effectively prevent certain developer power abusers
from
Post by Christopher Hart
creating shields. The customer is largely being excluded from the
team so
Post by Christopher Hart
that ivory-tower developers in white lab coats can take us back
decades.
Post by Christopher Hart
Ick.
The paradigm shift to XP is painful for both developers and
customers
Post by Christopher Hart
because it requires trust. However it also provides the mechanisms
to build
Post by Christopher Hart
trust. Unfortunately some people are using the name XP to disolve
trust.
Post by Christopher Hart
Again ick.
Best Regards,
Chris Hart
Thank you, Chris. Could you suggest one small thing I could change
about the paper so it would (better) address the issues you raise
above?
Kent
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Gee, Joe
2002-08-21 20:04:37 UTC
Permalink
Yes, well said as usual.
Post by Kent Beck
-----Original Message-----
Sent: Wednesday, August 21, 2002 1:57 PM
Subject: RE: [XP] FW: Are You Getting XPed On
Hi, Dale,
This is nice.
Kay
Post by Kent Beck
-----Original Message-----
Sent: Wednesday, August 21, 2002 2:58 PM
Subject: Re: [XP] FW: Are You Getting XPed On
Hi Kent,
Post by kentlbeck
Thank you, Chris. Could you suggest one small thing I
could change
Post by Kent Beck
Post by kentlbeck
about the paper so it would (better) address the issues you raise
above?
Though I'm not Chris, I do have a suggestion. I liked the article
<snip>
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kucera, Rich
2002-08-22 17:21:55 UTC
Permalink
well shoot. It all sounds so scary with all this exposure
and whatnot. I would think iteration, that is showing
a working system, is the only thing that would calm
everybody down.

One thing I've learned from iteration is you should
never show the customer the same demo more than once.
Isn't that in Anti-Patterns? Bought the t-shirt.


-----Original Message-----
From: Christopher Hart [mailto:***@hartedwards.com]
Sent: Wednesday, August 21, 2002 1:53 PM
To: ***@yahoogroups.com
Subject: Re: [XP] FW: Are You Getting XPed On
Post by Kucera, Rich
How does XP require more trust, if you are giving the customer the value
of what they are paying for now, that is sooner, than in the old way?
Seems to me XP removes some the requirement for trust, instead of
requiring more trust.
You have pair programming, planning, the onsite customer, metaphor, the
warroom environment, a faster release schedule, and other practices all
conspiring to foster trust through full disclosure and greater
communication. Won't work without trust. One of the greatest hinderances to
the acceptance of XP is trusting the developers/customers/other
department/others long enough to show results. Once the positive results are
in then additional trust can be built. How many developers sign up for
project when the customer is free to cancel at any point becuase he feels he
has enough business value? How many developers are comfortable with other
people constantly in their code and looking over their shoulders? How many
developers are comfortable having the customer right there? How many
developers are confident in their ability to make acurate estimates two
weeks out and commit to those? How many customers feel safe doing an open
ended contract? It's too easy to get burned by the other side by being held
accountable for what you have revealed. And the deeper you get in the more
exposed you are, however you can hedge this by all the instances of
delivering value.
Post by Kucera, Rich
In the old way, you'd do a BUFD, promising all this value you'd
deliver in the future. Seems to me that would require a lot of
trust on the customers part.
There is no trust in BDUF. The developers continually complain that users,
think drug-users for the right level of contempt, don't know what they want
and have unrealistic expectations. The customers think the developers are
lying about the schedule because either they can deliver faster and are too
lazy to do so, or it's going to be late and overbudget. Plus it's not going
to work or its going to be irrelevant. Developers routinely wing the predict
ion because they rarely have enough detail on the specs. They are often
forced to come up with a feel-good number/date so that the other side goes
away and lets them get something done. BDUF has no mechanisms to build trust
either. I trust you because I have to, and hopefully I can sue if I'm not
happy.
Post by Kucera, Rich
Again, not in the context of the power grab issue, which I don't
really get--why would developers want to get involved in that
cutthroat business--keep your freakin heads down.
Developers are human and don't appreciate being walked all over. It's either
play the game or get stomped on.

Gee...I sound cynical.

Best regards,

Chris


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-26 14:00:59 UTC
Permalink
Post by Christopher Hart
The examples also bring forward one of the failings in
communicating XP in that it is still too developer-centric.
[egb> ] But, isn't that the primary focus of XP (it's extreme <programming>
not extreme <project management>)? There are no specific best practices
therein that are directed to the project manager or other such stakeholders,
save for the issues surrounding the planning game...and that's a practice
that's not nearly at the same level of abstraction as those for the
developer (e.g. test first, pair programming)

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Palanza
2002-08-26 15:01:19 UTC
Permalink
Post by Booch, Grady
[egb> ] But, isn't that the primary focus of XP (it's extreme <programming>
not extreme <project management>)? There are no specific best practices
therein that are directed to the project manager or other such stakeholders,
save for the issues surrounding the planning game...and that's a practice
that's not nearly at the same level of abstraction as those for the
developer (e.g. test first, pair programming)
Interesting commentary.

In building construction we call a project manager the "general
contractor." I've been curiously waiting to see this contributor jell in
the XP philosophy, complementary to customer and separate from
implementation craft contributors, such as programmers and the overall
project design. In my attempts to do agile construction we get customer
versus contractor and craft-contributors versus design-team.
Craft-contributor and design-team both affect architecture but in different
ways. I don't see a way to reduce a balanced team below four such
categories, whatever one decides to name them.

Dan

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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-26 22:19:02 UTC
Permalink
Post by Dan Palanza
Post by Booch, Grady
[egb> ] But, isn't that the primary focus of XP (it's extreme <programming>
not extreme <project management>)? There are no specific best practices
therein that are directed to the project manager or other such stakeholders,
save for the issues surrounding the planning game...and that's a practice
that's not nearly at the same level of abstraction as those for the
developer (e.g. test first, pair programming)
Interesting commentary.
In building construction we call a project manager the "general
contractor." I've been curiously waiting to see this contributor jell in
the XP philosophy, complementary to customer and separate from
implementation craft contributors, such as programmers and the overall
project design. In my attempts to do agile construction we get customer
versus contractor and craft-contributors versus design-team.
Craft-contributor and design-team both affect architecture but in different
ways. I don't see a way to reduce a balanced team below four such
categories, whatever one decides to name them.
From what I've observed, the general contractor on a building project and a software development team operate in a very different manner. For example, in construction there is a very definite need for a separate design team, in XP development there shouldn't be a separate design team. Design is done on an ongoing basis as the program system is constructed; something that is simply impossible when creating a building.
To continue a bit further, the project manager in an XP project has much less administrative work to do, and much more people work to keep everything going smoothly. The general contractor on a building has a great deal of logistics work to insure that materials arrive at the work site when they are needed, for example.

John Roth
Post by Dan Palanza
Dan
[Non-text portions of this message have been removed]
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Palanza
2002-08-27 00:28:44 UTC
Permalink
Hi John,
Post by Dan Palanza
From what I've observed, the general contractor on a building project and
a software development team operate in a very different manner.
You seem to have missed an important point in my comments. I'm referring to
construction using iterative design, and not a typical building project
with a big up front design. IOW, construction typical of Christopher
Alexander's work. Alexander originated the pattern form as a way to
communicate what we now call agile, or iterative, design.
Post by Dan Palanza
For example, in construction there is a very definite need for a separate
design team, in XP development there shouldn't be a separate design team.
Construction has no more need for a separate up front design team than
software has. The iterative approach does away with up front design for all
the same reasons that come up in both disciplines.
Post by Dan Palanza
Design is done on an ongoing basis as the program system is constructed;
My comments speak of two types of design. Design by the craft contributor,
which is done on an on-going basis, and design by leadership people who
have experience with a project typical of the one being implemented. XP is
doing a good job of working out the role of software craft persons using
TDD. I don't see much being done in the way of leadership oriented design,
hence my comments.
Post by Dan Palanza
something that is simply impossible when creating a building.
In fact on-going design in construction can and is being done quite nicely.
What is more, it happens more often than one might imagine.

Dan

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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-27 13:26:18 UTC
Permalink
Post by Dan Palanza
Hi John,
Post by Dan Palanza
From what I've observed, the general contractor on a building project and
a software development team operate in a very different manner.
You seem to have missed an important point in my comments. I'm referring to
construction using iterative design, and not a typical building project
with a big up front design. IOW, construction typical of Christopher
Alexander's work. Alexander originated the pattern form as a way to
communicate what we now call agile, or iterative, design.
May I make the same point? Once you've poured the concrete and put up steel, making any fundamental change (like how wide the building is) will cost you both arms and a leg. Everything up to the point of getting the construction trailer on the lot and starting to dig the place up corresponds to _big, up front design_. It's easy to see this if you look. I've never seen anyone live inside a blueprint, or an architects model.

In XP, the result of design is, in fact, the final system the customer wanted. There is no separate design phase that simply produces paper that the construction process uses.

Or maybe Alexander created a way of making concrete and steel flow like code? Somehow, I don't think so.

John Roth



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-27 17:44:06 UTC
Permalink
Post by Dan Palanza
Post by Dan Palanza
Hi John,
Post by Dan Palanza
From what I've observed, the general contractor on a
building project and
Post by Dan Palanza
Post by Dan Palanza
a software development team operate in a very different manner.
You seem to have missed an important point in my comments.
I'm referring to
Post by Dan Palanza
construction using iterative design, and not a typical
building project
Post by Dan Palanza
with a big up front design. IOW, construction typical of
Christopher
Post by Dan Palanza
Alexander's work. Alexander originated the pattern form as a way to
communicate what we now call agile, or iterative, design.
May I make the same point? Once you've poured the concrete
and put up steel, making any fundamental change (like how
wide the building is) will cost you both arms and a leg.
Everything up to the point of getting the construction
trailer on the lot and starting to dig the place up
corresponds to _big, up front design_. It's easy to see this
if you look. I've never seen anyone live inside a blueprint,
or an architects model.
In XP, the result of design is, in fact, the final system the
customer wanted. There is no separate design phase that
simply produces paper that the construction process uses.
I disagree with this. In XP the result is a system running on an integration
machine that does what the person[s] playing the Customer Role wanted. It
must still be moved onto the actual user's machines, adapted to actual
user's needs, and so on. UP calls this phase Transition, and it comes
/after/ development... and is outside XP's scope as it is currently
defined... of course, for the most successful XP projects this move should
be small, but it often isn't - look at C3 where the system died as it was
being transitioned

This software transition corresponds almost exactly to moving the blueprints
and models from the Engineer's and Architect's locations and instantiating
them in concrete and rebar on the actual site. The development phase has
been finished, this is only the transition phase...

In both software and construction there can be many decisions that need to
be made in the transition phase. Think of installing SAP, for example. And
these transition projects can grow so large that they can look like their
own development projects. However, they are working within the constraints
imposed by the original development projects, such as predefined interfaces
or concrete footprints...

Dan ;-)
Post by Dan Palanza
Or maybe Alexander created a way of making concrete and steel
flow like code? Somehow, I don't think so.
John Roth
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-27 20:09:45 UTC
Permalink
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Palanza
Hi John,
Post by Dan Palanza
From what I've observed, the general contractor on a
building project and
Post by Dan Palanza
Post by Dan Palanza
a software development team operate in a very different manner.
You seem to have missed an important point in my comments.
I'm referring to
Post by Dan Palanza
construction using iterative design, and not a typical
building project
Post by Dan Palanza
with a big up front design. IOW, construction typical of
Christopher
Post by Dan Palanza
Alexander's work. Alexander originated the pattern form as a way to
communicate what we now call agile, or iterative, design.
May I make the same point? Once you've poured the concrete
and put up steel, making any fundamental change (like how
wide the building is) will cost you both arms and a leg.
Everything up to the point of getting the construction
trailer on the lot and starting to dig the place up
corresponds to _big, up front design_. It's easy to see this
if you look. I've never seen anyone live inside a blueprint,
or an architects model.
In XP, the result of design is, in fact, the final system the
customer wanted. There is no separate design phase that
simply produces paper that the construction process uses.
I disagree with this. In XP the result is a system running on an integration
machine that does what the person[s] playing the Customer Role wanted. It
must still be moved onto the actual user's machines, adapted to actual
user's needs, and so on. UP calls this phase Transition, and it comes
/after/ development... and is outside XP's scope as it is currently
defined... of course, for the most successful XP projects this move should
be small, but it often isn't - look at C3 where the system died as it was
being transitioned.
It's perfectly true that the system must be deployed, but deployment is most definitely not outside of the scope of XP! I can very easily see a story that says something like: "Make it easy to install." That would have to be estimated, acceptance tests written, developed and so forth. Done well, actual deployment should then be a matter of pressing the button.

Of course needs differ. Shrink-wrap is not the same as an internal enterprise system, which is not the same as a professional level system that may require customization for each individual customer. In each case, there are problems to be solved that can be dealt with by the XP development team.

As far as C3 is concerned, I wasn't there. Your statement doesn't match my understanding of what went on, but someone who was there would have to clarify.
Post by Dan Rawsthorne
This software transition corresponds almost exactly to moving the blueprints
and models from the Engineer's and Architect's locations and instantiating
them in concrete and rebar on the actual site. The development phase has
been finished, this is only the transition phase...
In both software and construction there can be many decisions that need to
be made in the transition phase. Think of installing SAP, for example.
I'd rather not, thank you very much.
Post by Dan Rawsthorne
And
these transition projects can grow so large that they can look like their
own development projects. However, they are working within the constraints
imposed by the original development projects, such as predefined interfaces
or concrete footprints...
Why can't they change them if they need to? Shared code ownership means exactly that: there is nothing in the system that is sacred. The development team that makes the change simply has to take the responsibility for all ramifications of the change, which may not be feasible in all cases.

The whole point I'm trying to get across is that there is no _necessary_ step in program development that corresponds to pouring the concrete, putting up the steel and fleshing out the rather obdurate physical artifact that is a building. Building construction is a very bad metaphor for program development, and using it leads to all kinds of problems. Like the mess down here in Atlanta with the state department of child welfare (whatever it's actually called) losing track of several children that subsequently died of child abuse while the system that was supposed to track them is still not built after several false starts (and umpteen years of spending taxpayers money on failed projects). And the idiot in charge of the project was quoted, in print (last Sunday's Atlanta Journal-Constitution, front page article) as justifying yet another year long system study on the basis that these systems are so hard to change that you have to have massive planning up front.

John Roth
Post by Dan Rawsthorne
Dan ;-)
Post by Dan Palanza
Or maybe Alexander created a way of making concrete and steel
flow like code? Somehow, I don't think so.
John Roth
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-27 21:24:47 UTC
Permalink
Post by Dan Palanza
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Palanza
Hi John,
Post by Dan Palanza
From what I've observed, the general contractor on a
building project and
Post by Dan Palanza
Post by Dan Palanza
a software development team operate in a very
different manner.
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Palanza
You seem to have missed an important point in my comments.
I'm referring to
Post by Dan Palanza
construction using iterative design, and not a typical
building project
Post by Dan Palanza
with a big up front design. IOW, construction typical of
Christopher
Post by Dan Palanza
Alexander's work. Alexander originated the pattern form
as a way to
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Palanza
communicate what we now call agile, or iterative, design.
May I make the same point? Once you've poured the concrete
and put up steel, making any fundamental change (like how
wide the building is) will cost you both arms and a leg.
Everything up to the point of getting the construction
trailer on the lot and starting to dig the place up
corresponds to _big, up front design_. It's easy to see this
if you look. I've never seen anyone live inside a blueprint,
or an architects model.
In XP, the result of design is, in fact, the final system the
customer wanted. There is no separate design phase that
simply produces paper that the construction process uses.
I disagree with this. In XP the result is a system running on an integration
machine that does what the person[s] playing the Customer Role wanted. It
must still be moved onto the actual user's machines, adapted to actual
user's needs, and so on. UP calls this phase Transition, and it comes
/after/ development... and is outside XP's scope as it is currently
defined... of course, for the most successful XP projects this move should
be small, but it often isn't - look at C3 where the system died as it was
being transitioned.
It's perfectly true that the system must be deployed, but
deployment is most definitely not outside of the scope of XP!
Sure, it is. It is probably within the scope of the project, as you say
below. But it is certainly outside the scope of the XP process, itself. The
Customer is the interface with the "outside world", and that is basically
the extent of the direction of XP. How this interface is managed, what the
activities are, and so on, are outside XP's scope. At least I don't see any
practices (among the basic 12, at least) that comes close to addressing this
problem. Certainly within the project's scope, of course - but that's a
completely different thing...
Post by Dan Palanza
I can very easily see a story that says something like: "Make
it easy to install." That would have to be estimated,
acceptance tests written, developed and so forth. Done well,
actual deployment should then be a matter of pressing the button.
That would be nice. Of course, it presupposes that the Customer knows what
it takes to deploy the software, because he/she comes up with the story. For
those cases where the Customer is not the user there is a built in
disconnect. How complex and difficult to solve this problem is is up to the
project, of course...
Post by Dan Palanza
Of course needs differ. Shrink-wrap is not the same as an
internal enterprise system, which is not the same as a
professional level system that may require customization for
each individual customer. In each case, there are problems to
be solved that can be dealt with by the XP development team.
Bingo! My point exactly. This is the project's problem, but not addressed by
the XP practices... they must be solved by using something else. The XP
practices stop short of actually pouring the concrete at the actual user's
site. By definition, XP stops with "it works on our integration machine,
where 'works' means it does what our Customer told us..." This is a far cry
from "it works on all our user's machines, and they're all happy with it..."
Post by Dan Palanza
As far as C3 is concerned, I wasn't there. Your statement
doesn't match my understanding of what went on, but someone
who was there would have to clarify.
I wish we knew the details, too. My understanding is that the HR/Payroll
department (the actual users) didn't deploy the system to write everybody's
checks. So, even though the software was largely written and worked, it
never made it through transition to the actual users...
Post by Dan Palanza
Post by Dan Rawsthorne
This software transition corresponds almost exactly to moving the blueprints
and models from the Engineer's and Architect's locations and
instantiating
Post by Dan Palanza
Post by Dan Rawsthorne
them in concrete and rebar on the actual site. The development phase has
been finished, this is only the transition phase...
In both software and construction there can be many decisions that need to
be made in the transition phase. Think of installing SAP, for example.
I'd rather not, thank you very much.
Can't say that I blame you. :)
Post by Dan Palanza
Post by Dan Rawsthorne
And
these transition projects can grow so large that they can
look like their
Post by Dan Rawsthorne
own development projects. However, they are working within
the constraints
Post by Dan Rawsthorne
imposed by the original development projects, such as
predefined interfaces
Post by Dan Rawsthorne
or concrete footprints...
Why can't they change them if they need to? Shared code
ownership means exactly that: there is nothing in the system
that is sacred. The development team that makes the change
simply has to take the responsibility for all ramifications
of the change, which may not be feasible in all cases.
Yeah, but these guys aren't sharing in the ownership. Development is
finished, we are in transition. The only changes that can be made are bug
fixes and cosmetic... if you are making more changes than that then you go
back into development...
Post by Dan Palanza
The whole point I'm trying to get across is that there is no
_necessary_ step in program development that corresponds to
pouring the concrete, putting up the steel and fleshing out
the rather obdurate physical artifact that is a building.
Sure there is. At a minimum it's an installation... see the discussion below
Post by Dan Palanza
Building construction is a very bad metaphor for program
development, and using it leads to all kinds of problems.
Agree. Luckily, we're not talking about construction versus development -
they really are different things. The similarities I see are between:
- software development and engineering
- transition and construction
Post by Dan Palanza
Like the mess down here in Atlanta with the state department
of child welfare (whatever it's actually called) losing track
of several children that subsequently died of child abuse
while the system that was supposed to track them is still not
built after several false starts (and umpteen years of
spending taxpayers money on failed projects). And the idiot
in charge of the project was quoted, in print (last Sunday's
Atlanta Journal-Constitution, front page article) as
justifying yet another year long system study on the basis
that these systems are so hard to change that you have to
have massive planning up front.
<cynical>
Unfortunatly, he's probably right. If the system was not developed well, it
is hard to change. Of course, I disagree with his solution. But you gotta
understand that his job is to keep the project alive, it's his client's job
to worry about it doing the right thing...
</cynical>

This is a very sad story, but I don't see how it pertains to the point being
debated here. The question is "is moving software from development to use
similar to moving a building from plans to concrete?" My claim is that the
analogy holds, yours seems to be that it doesn't...

I can imagine that in an extremely small, close-knit software organization
it is possible for the Customer to actually be the users, and the actual
live system being run off the integration machine.

But, in any "real" environment you have to move the system off the
integration machine, install it on a user's machine, train somebody how to
use it, and so on. It's also likely that changes to the user's version of
the system happen at a slower rate than changes to the code on the
integration machine (updated every n iterations versus many times a day...).
This process of moving from the integration machine to the user's
environment is called Transition (by UP), and is precisely analogous to
erecting the building for people to move into.

The only real difference is that a building gets significant updates every
decade or so, while software gets them annually or quarterly, or
something... of course, the other difference is that the transition of
software typically takes hours/days/weeks while the transition of plans to a
building takes weeks/months/years. Of course, the transitioning of an ERP
system to a large corporation is similar to the construction of a small
office building - and costs are similar, too...

It's certainly not a question of software development and civil (or any
other kind) engineering being different things - they certainly are... but
there are more similarities than differences, IMHO

Dan ;-)
Post by Dan Palanza
John Roth
Post by Dan Rawsthorne
Dan ;-)
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-28 12:06:20 UTC
Permalink
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Palanza
Hi John,
Post by Dan Palanza
From what I've observed, the general contractor on a
building project and
Post by Dan Palanza
Post by Dan Palanza
a software development team operate in a very
different manner.
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Palanza
You seem to have missed an important point in my comments.
I'm referring to
Post by Dan Palanza
construction using iterative design, and not a typical
building project
Post by Dan Palanza
with a big up front design. IOW, construction typical of
Christopher
Post by Dan Palanza
Alexander's work. Alexander originated the pattern form
as a way to
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Palanza
communicate what we now call agile, or iterative, design.
May I make the same point? Once you've poured the concrete
and put up steel, making any fundamental change (like how
wide the building is) will cost you both arms and a leg.
Everything up to the point of getting the construction
trailer on the lot and starting to dig the place up
corresponds to _big, up front design_. It's easy to see this
if you look. I've never seen anyone live inside a blueprint,
or an architects model.
In XP, the result of design is, in fact, the final system the
customer wanted. There is no separate design phase that
simply produces paper that the construction process uses.
I disagree with this. In XP the result is a system running on an
integration
Post by Dan Palanza
Post by Dan Rawsthorne
machine that does what the person[s] playing the Customer Role wanted.
It
Post by Dan Palanza
Post by Dan Rawsthorne
must still be moved onto the actual user's machines, adapted to actual
user's needs, and so on. UP calls this phase Transition, and it comes
/after/ development... and is outside XP's scope as it is currently
defined... of course, for the most successful XP projects this move
should
Post by Dan Palanza
Post by Dan Rawsthorne
be small, but it often isn't - look at C3 where the system died as it
was
Post by Dan Palanza
Post by Dan Rawsthorne
being transitioned.
It's perfectly true that the system must be deployed, but
deployment is most definitely not outside of the scope of XP!
Sure, it is. It is probably within the scope of the project, as you say
below. But it is certainly outside the scope of the XP process, itself. The
Customer is the interface with the "outside world", and that is basically
the extent of the direction of XP. How this interface is managed, what the
activities are, and so on, are outside XP's scope. At least I don't see any
practices (among the basic 12, at least) that comes close to addressing this
problem. Certainly within the project's scope, of course - but that's a
completely different thing...
It's actually not a different thing. When the builder turns a new building over to the customer, very different things happen depending on the customer. Some customers will want to handle moving their stuff from the old building themselves (or employ a separate contractor to do so,) some want the builder to turn it over so that all the employees can simply walk in Monday morning and pick up their jobs.

As you may have figured out, my background is IT. Installation is always part of the project. You think anyone in their right mind is going to turn installation of an application on the corporate mainframe over to the accounting department?

The same thing applies to PC applications. Every project I've ever worked on that has client side software, the customer has always asked for easier installation procedures, right down to "make it magic. Just get it on those *#$!@+!* machines so it's there when they walk in Monday morning."

The entire notion that deployment is outside of the scope of XP completely baffles me.
Post by Dan Rawsthorne
Post by Dan Palanza
I can very easily see a story that says something like: "Make
it easy to install." That would have to be estimated,
acceptance tests written, developed and so forth. Done well,
actual deployment should then be a matter of pressing the button.
That would be nice. Of course, it presupposes that the Customer knows what
it takes to deploy the software, because he/she comes up with the story. For
those cases where the Customer is not the user there is a built in
disconnect. How complex and difficult to solve this problem is is up to the
project, of course...
Post by Dan Palanza
Of course needs differ. Shrink-wrap is not the same as an
internal enterprise system, which is not the same as a
professional level system that may require customization for
each individual customer. In each case, there are problems to
be solved that can be dealt with by the XP development team.
Bingo! My point exactly. This is the project's problem, but not addressed by
the XP practices... they must be solved by using something else. The XP
practices stop short of actually pouring the concrete at the actual user's
site. By definition, XP stops with "it works on our integration machine,
where 'works' means it does what our Customer told us..." This is a far cry
from "it works on all our user's machines, and they're all happy with it..."
Where is that defined? AFIK, all XP says is that the customer receives a production quality product after every iteration. It says nothing about an "integration machine." If the system is going to be deployed on a workstation, I interpret that to mean that they've got the actual package that will go on their workstations. There's no other way to interpret it and still satisfy the feedback value.

If it's going to be deployed on a server complex somewhere, then it may very well be delivered on a test machine, or it may not, depending on the system. Even if it is delivered on a test machine, the customer is most likely not going to personally install it on the production server(s).

Continuing on a bit, there's no such thing as an "integration machine" within XP. The version on the code repository is _always_ the latest production version, no need of a separate integration pass.
Post by Dan Rawsthorne
Post by Dan Palanza
As far as C3 is concerned, I wasn't there. Your statement
doesn't match my understanding of what went on, but someone
who was there would have to clarify.
I wish we knew the details, too. My understanding is that the HR/Payroll
department (the actual users) didn't deploy the system to write everybody's
checks. So, even though the software was largely written and worked, it
never made it through transition to the actual users...
That's my understanding. Corporate politics (a major buyout and merger, with major replacement of upper management) got in the way. Nothing to do with the XP methodology. Chrysler became Damlier-Chrysler in the process.
Post by Dan Rawsthorne
Post by Dan Palanza
Post by Dan Rawsthorne
This software transition corresponds almost exactly to moving the
blueprints
Post by Dan Palanza
Post by Dan Rawsthorne
and models from the Engineer's and Architect's locations and
instantiating
Post by Dan Palanza
Post by Dan Rawsthorne
them in concrete and rebar on the actual site. The development phase has
been finished, this is only the transition phase...
In both software and construction there can be many decisions that need
to
Post by Dan Palanza
Post by Dan Rawsthorne
be made in the transition phase. Think of installing SAP, for example.
I'd rather not, thank you very much.
Can't say that I blame you. :)
Post by Dan Palanza
Post by Dan Rawsthorne
And
these transition projects can grow so large that they can
look like their
Post by Dan Rawsthorne
own development projects. However, they are working within
the constraints
Post by Dan Rawsthorne
imposed by the original development projects, such as
predefined interfaces
Post by Dan Rawsthorne
or concrete footprints...
Why can't they change them if they need to? Shared code
ownership means exactly that: there is nothing in the system
that is sacred. The development team that makes the change
simply has to take the responsibility for all ramifications
of the change, which may not be feasible in all cases.
Yeah, but these guys aren't sharing in the ownership. Development is
finished, we are in transition. The only changes that can be made are bug
fixes and cosmetic... if you are making more changes than that then you go
back into development...
That's someplace where XP currently doesn't go. XP has a very explicit presupposition that the development team can change whatever they need to so that the design remains consistent.

The other point here is that there is no "go back into development." One thing that isn't emphasized very much is that XP is not a "development" methodology in the classical sense. It's a _maintenance_ methodology that works very, very well as a development methodology. Everything that is done in XP is, in fact, maintenance of what has been done before.
Post by Dan Rawsthorne
Post by Dan Palanza
The whole point I'm trying to get across is that there is no
_necessary_ step in program development that corresponds to
pouring the concrete, putting up the steel and fleshing out
the rather obdurate physical artifact that is a building.
Sure there is. At a minimum it's an installation... see the discussion below
Post by Dan Palanza
Building construction is a very bad metaphor for program
development, and using it leads to all kinds of problems.
Agree. Luckily, we're not talking about construction versus development -
- software development and engineering
- transition and construction
Post by Dan Palanza
Like the mess down here in Atlanta with the state department
of child welfare (whatever it's actually called) losing track
of several children that subsequently died of child abuse
while the system that was supposed to track them is still not
built after several false starts (and umpteen years of
spending taxpayers money on failed projects). And the idiot
in charge of the project was quoted, in print (last Sunday's
Atlanta Journal-Constitution, front page article) as
justifying yet another year long system study on the basis
that these systems are so hard to change that you have to
have massive planning up front.
<cynical>
Unfortunatly, he's probably right. If the system was not developed well, it
is hard to change. Of course, I disagree with his solution. But you gotta
understand that his job is to keep the project alive, it's his client's job
to worry about it doing the right thing...
His job seems to be to keep his job. If his job was getting the systems working that his employer, the Georgia State legislature, and the Federal government have mandated, he would be asking real simple questions like: "If doing it this way has failed, then shouldn't we be looking at another way of doing it?"
Post by Dan Rawsthorne
</cynical>
This is a very sad story, but I don't see how it pertains to the point being
debated here. The question is "is moving software from development to use
similar to moving a building from plans to concrete?" My claim is that the
analogy holds, yours seems to be that it doesn't...
I think that's a good summary.
Post by Dan Rawsthorne
I can imagine that in an extremely small, close-knit software organization
it is possible for the Customer to actually be the users, and the actual
live system being run off the integration machine.
But, in any "real" environment you have to move the system off the
integration machine, install it on a user's machine, train somebody how to
use it, and so on. It's also likely that changes to the user's version of
the system happen at a slower rate than changes to the code on the
integration machine (updated every n iterations versus many times a day...).
This process of moving from the integration machine to the user's
environment is called Transition (by UP), and is precisely analogous to
erecting the building for people to move into.
The only real difference is that a building gets significant updates every
decade or so, while software gets them annually or quarterly, or
something...
Canonical XP recommends six weeks to two months. There are projects that move to production every night! When you deploy the application depends on the customer's needs, and how sophisticated their infratstructure is. There's no one right answer, because situations vary all over the lot.
Post by Dan Rawsthorne
of course, the other difference is that the transition of
software typically takes hours/days/weeks while the transition of plans to a
building takes weeks/months/years.
There's an even more fundamental distinction. The "holy grail" of software deployment is to make it invisible. It just happens. That's coming closer and closer all the time; look at what happens with the latest Microsoft (and other) systems, where they will simply update your system for you.

I'd love to contract with Aladdin's Genie to get my buildings constructed, but I seriously doubt that it's ever going to happen that way.
Post by Dan Rawsthorne
Of course, the transitioning of an ERP
system to a large corporation is similar to the construction of a small
office building - and costs are similar, too...
That's an example of a framework. If you _have_ to tailor it in any more significant manner than putting your corporate logo on it, then it's not an installable application; it's an application framework. The actual customer is the organization that will customize it for the next customer down the food chain.
Post by Dan Rawsthorne
It's certainly not a question of software development and civil (or any
other kind) engineering being different things - they certainly are... but
there are more similarities than differences, IMHO
The biggest point I'm trying to make, and I seem to not be doing that good a job at it, is that the architect for a building, or the designer for a bridge, or whatever, does not produce an artifact that can be put into production to produce feedback. The actual artifact that can produce valid feedback is _very_ expensive to produce, and also _very_ expensive to modify, so it really should be done right the first time. Fortunately, we (as a culture) have managed to get that part down reasonably well.

XP specifically, and the various agile methodologies in general, take the exactly opposite tack. We want artifacts that we can change easily and (relatively) inexpensively. We don't want anything that is even roughly analogous to digging a hole, pouring concrete and erecting structural steel. That's too expensive, too inflexible, and takes too long.

In other words, all the concrete and steel of a building is essentially the way it is. All the fuss and bother of deploying an application is a deplorable fact that we want to get rid of as rapidly as possible.

Is that clear, or is there anything else I can do to get my point across?

John Roth
Post by Dan Rawsthorne
Dan ;-)
Post by Dan Palanza
John Roth
Post by Dan Rawsthorne
Dan ;-)
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-28 16:14:29 UTC
Permalink
This is getting big, so I'll address only a small snip this time...

jhrothjr [mailto:***@jhrothjr.com]
<snip>
Post by jhrothjr
As you may have figured out, my background is IT.
Installation is always part of the project. You think anyone
in their right mind is going to turn installation of an
application on the corporate mainframe over to the accounting
department?
This explains a lot. My initial software experience was with military (and
other government) systems. In IT the delta between your XP Customer and your
actual users is fairly small. In military systems we often never get to meet
an actual user... and you /never/ get to meet one that is current with the
technology. For example, if you get a real Navy Pilot on your site, it's
gonna be somebody that hasn't flown in 3-4 years, and was retrained as an
Acquisition Officer. You usually can't get one of these, so you hire an
ex-pilot to be on your team. If you're real lucky you get a young guy who
just got out, and has some experience in the plane you're dealing with.

Additionally, we almost never get to do the installations on the actual
hardware (like an airplane)... there is usually a whole other contractor
whose job that is. You do, however, get to develop training materials so
that some military trainer can teach him to install it. The levels of
indirection are incredible, sometimes...

So, when you ask "is someone in their right mind..." the answer is "yes,
people in their right mind do that all the time." There is a move in the
military to actually let geeks go out on "shakedown" cruises to make sure
that their systems work, and this is a good thing. Unfortunately, everybody
wants to go on the cruise, and the one who does go is seldom the right guy,
IMHO... but that's another story.
Post by jhrothjr
The same thing applies to PC applications. Every project I've
ever worked on that has client side software, the customer
has always asked for easier installation procedures, right
machines so it's there when they walk in Monday morning."
In IT installation is usually as simple as carrying a CD to a workstation
and just "making it work" - in my experience it usually takes from 15
minutes to an hour. On the other hand, I spent over a year on an Air Traffic
Control contract trying to answer the following question: "assuming we had
new ATC software, how could we install it nationwide (350 locations) so that
there is no break in service?" The costs and risks of this transition are
huge, and the existence of the transition problem drives a lot of the
software/hardware requirements for the new system.

Dan ;-)

<snip>


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-28 17:05:23 UTC
Permalink
jhrothjr [mailto:***@jhrothjr.com]
<snip>
Post by jhrothjr
It's actually not a different thing. When the builder turns a
new building over to the customer, very different things
happen depending on the customer. Some customers will want to
handle moving their stuff from the old building themselves
(or employ a separate contractor to do so,) some want the
builder to turn it over so that all the employees can simply
walk in Monday morning and pick up their jobs.
Here we go mixing up the building process and the engineering process again.
The transition I am talking about is the transition from the building as
engineered (blueprints, etc) to the building as constructed. This
corresponds to the transition of a system from where the XP team is to where
the users are. Sometimes this transition is easy (even automatic), sometimes
it is hard (like moving an Air Traffic Control system from the lab in New
Jersey to service across the US). XP says that it would really be nice if
you could do this transition all the time... no problem with that
sentiment - it's the right thing to do and say. It just can't be done in
many cases. But you'd still like to use XP to build the software, right? I
would...

<snip>
Post by jhrothjr
That's my understanding. Corporate politics (a major buyout
and merger, with major replacement of upper management) got
in the way. Nothing to do with the XP methodology. Chrysler
became Damlier-Chrysler in the process.
We're agreeing again. Yes, the failure of the project had nothing to do with
XP. That is precisely my point. The transition of the C3 system from where
it was to where it ultimately should have been was outside the scope of the
project.

<snip>
Post by jhrothjr
Post by Dan Rawsthorne
Post by jhrothjr
Why can't they change them if they need to? Shared code
ownership means exactly that: there is nothing in the system
that is sacred. The development team that makes the change
simply has to take the responsibility for all ramifications
of the change, which may not be feasible in all cases.
Yeah, but these guys aren't sharing in the ownership. Development is
finished, we are in transition. The only changes that can be made are bug
fixes and cosmetic... if you are making more changes than that then you go
back into development...
That's someplace where XP currently doesn't go. XP has a very
explicit presupposition that the development team can change
whatever they need to so that the design remains consistent.
We're agreeing again. In the real world when these situations arise (and
they do), XP doesn't go there. This sort of transition is outside the scope
of XP. We agree. That doesn't mean the situations don't exist, or that you
don't develop the software using XP, though...
Post by jhrothjr
The other point here is that there is no "go back into
development." One thing that isn't emphasized very much is
that XP is not a "development" methodology in the classical
sense. It's a _maintenance_ methodology that works very, very
well as a development methodology. Everything that is done in
XP is, in fact, maintenance of what has been done before.
Probably should have used the phrase "go back to development", not "into".
When problems in transition require changes in the code, you must go back to
the development team (your XP team) to make the changes. One of the biggest
problems we have in Air Traffic Control system is on-site changes to code,
done by local maintainers. For example, the code in Alaska has very little
resemblence to what it started off as, and nation-wide upgrades can't be
integrated into the Alaska system very easily...
<snip>
Post by jhrothjr
There's an even more fundamental distinction. The "holy
grail" of software deployment is to make it invisible. It
just happens. That's coming closer and closer all the time;
look at what happens with the latest Microsoft (and other)
systems, where they will simply update your system for you.
I'd love to contract with Aladdin's Genie to get my buildings
constructed, but I seriously doubt that it's ever going to
happen that way.
It's getting close. You can erect a pre-fabbed house in 2 days...
<snip>
Post by jhrothjr
That's an example of a framework. If you _have_ to tailor it
in any more significant manner than putting your corporate
logo on it, then it's not an installable application; it's an
application framework. The actual customer is the
organization that will customize it for the next customer
down the food chain.
Two different projects, right? You have one project to build the framework,
and another project to transition the framework to the customer. Each is
producing software, each can be done using XP, but the first project doesn't
work with actual users very often...

<snip>
Post by jhrothjr
The biggest point I'm trying to make, and I seem to not be
doing that good a job at it, is that the architect for a
building, or the designer for a bridge, or whatever, does not
produce an artifact that can be put into production to
produce feedback. The actual artifact that can produce valid
feedback is _very_ expensive to produce, and also _very_
expensive to modify, so it really should be done right the
first time. Fortunately, we (as a culture) have managed to
get that part down reasonably well.
XP specifically, and the various agile methodologies in
general, take the exactly opposite tack. We want artifacts
that we can change easily and (relatively) inexpensively. We
don't want anything that is even roughly analogous to digging
a hole, pouring concrete and erecting structural steel.
That's too expensive, too inflexible, and takes too long.
Oh, I understand your point very well. I just disagree with it. The goal of
both engineering (and XP) is to do a lot of modeling and evaluation, usually
in tight iterative loops. One of the things that makes XP brilliant is that
it understands this concept the same way most engineers do. In both cases
the developers/engineers want to make sure that once the product gets in the
hands of users that it does what it is intended to do. With XP we're lucky -
we get to model in the actual medium. Sometimes we get to model in the
actual medium in the actual environment, like landscape architects, very
cool! This makes the evaluations much easier, as you're evaluating with the
actual users, all the time. This is similar to Lockheed's skunkworks
development of aircraft, where they actually built and crashed real
airplanes every few days...

Of course, sometimes we don't have the luxury of being in the actual
environment. So we evaluate as best we can with our Customer, and somebody
(maybe us) is going to wind up installing it. When this installation happens
we sometimes we get to do stuff that is analogous to digging holes, pouring
concrete, and so on. Gotta upgrade some hardware, networking, have a cutover
plan, all that stuff. This could be part of our project, or not, but it's
gotta get done by somebody.
Post by jhrothjr
In other words, all the concrete and steel of a building is
essentially the way it is. All the fuss and bother of
deploying an application is a deplorable fact that we want to
get rid of as rapidly as possible.
Yeah, that's the same way most civil engineers feel. They want to design,
model, test, evaluate, and so on. All the stuff that leads to the code (the
blueprints). Then they just want the actual construction and deployment
process to be automatic and painless. Very few of them want to be the
Construction Engineer. In our business it's like the difference between a
software developer and a SysAdmin.
Post by jhrothjr
Is that clear, or is there anything else I can do to get my
point across?
Your point is well understood. Just disagreed with.

Dan ;-)
Post by jhrothjr
John Roth
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 02:04:22 UTC
Permalink
Post by Dan Rawsthorne
I disagree with this. In XP the result is a system running on an integration
machine that does what the person[s] playing the Customer Role wanted. It
must still be moved onto the actual user's machines, adapted to actual
user's needs, and so on. UP calls this phase Transition, and it comes
/after/ development... and is outside XP's scope as it is currently
defined... of course, for the most successful XP projects this move should
be small, but it often isn't -
Sorry, I think this is incorrect. XP is all Transition Phase. You're
supposed to SHIP it.
Post by Dan Rawsthorne
look at C3 where the system died as it was
being transitioned
This, too, is incorrect. C3 was in actual production for over three
years.

Ron Jeffries
www.XProgramming.com
Knowledge must come through action;
you can have no test which is not fanciful,
save by trial. -- Sophocles


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-28 04:22:03 UTC
Permalink
Post by Ron Jeffries
Post by Dan Rawsthorne
I disagree with this. In XP the result is a system running on an integration
machine that does what the person[s] playing the Customer Role wanted. It
must still be moved onto the actual user's machines, adapted to actual
user's needs, and so on. UP calls this phase Transition, and it comes
/after/ development... and is outside XP's scope as it is currently
defined... of course, for the most successful XP projects this move should
be small, but it often isn't -
Sorry, I think this is incorrect. XP is all Transition Phase. You're
supposed to SHIP it.
I don't see much transition phase in the XP practices. If you use the
definition of Transition that UP does, then no development happens, only
adaptation and bug fixes. What I see in XP is the development of "working
releases" on integration machines, but not so much about shipping software
to actual users. That's not a knock on XP, it's just a statement that this
part of a project is outside XP's scope as currently defined by the 12-13
practices...

I believe that some XP projects believe in moving from integration machines
to actual users very often, but I don't see that as a documented practice -
not even in your book :) What I see is that the definition of release is
"make the code on the integration machine the official version" (pink, pg
123). This is very cool, but there is still the transition of this official
version out to users. This is precisely what UP calls the Transition
phase... it includes all the alpha, beta, etc stuff leading up to final
acceptance by the user community. Since "the outermost XP cycle is the
release" (pink, 49), it is clear that the cycle of moving to the actual
users (transition) is outside XP's scope, at least according to the pink
book :)
Post by Ron Jeffries
Post by Dan Rawsthorne
look at C3 where the system died as it was being transitioned
This, too, is incorrect. C3 was in actual production for over three years.
I've always misunderstood this. It was actually used by Chrysler to cut all
its payroll checks? As I understood it was in beta testing cutting some of
the checks... and then was not accepted for use by the whole company. That
is, it died during Transition...

Of course, it may never have been intended for continued use within
Chrysler, or to be used to cut all the checks - I don't know.

Dan ;-)
Post by Ron Jeffries
Ron Jeffries
www.XProgramming.com
Knowledge must come through action;
you can have no test which is not fanciful,
save by trial. -- Sophocles
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 11:24:37 UTC
Permalink
Post by Dan Rawsthorne
I don't see much transition phase in the XP practices. If you use the
definition of Transition that UP does, then no development happens, only
adaptation and bug fixes. What I see in XP is the development of "working
releases" on integration machines, but not so much about shipping software
to actual users. That's not a knock on XP, it's just a statement that this
part of a project is outside XP's scope as currently defined by the 12-13
practices...
I believe that some XP projects believe in moving from integration machines
to actual users very often, but I don't see that as a documented practice -
not even in your book :) What I see is that the definition of release is
"make the code on the integration machine the official version" (pink, pg
123). This is very cool, but there is still the transition of this official
version out to users. This is precisely what UP calls the Transition
phase... it includes all the alpha, beta, etc stuff leading up to final
acceptance by the user community. Since "the outermost XP cycle is the
release" (pink, 49), it is clear that the cycle of moving to the actual
users (transition) is outside XP's scope, at least according to the pink
book :)
I do apologize for not making this clear before now, Dan. However ...

In "Small Releases", Chapter 7, the precis says

The outermost XP cycle is the release. Small and frequent releases
provide early benefit to the customer while providing early
feedback to the programmers. Here are some thoughts on how to make
it happen.

The chapter goes on with things like:

If possible, wait no more than two months to release a version of
the software, and release every couple of months thereafter. And
we don't mean a demo version; we mean an actual version that does
something useful.

(We were wimpy here. That whole every two months is way too long.)

Then it goes on to describe how we could have (and should have IMO)
released the payroll incrementally. Then ideas for a personnel system.
Then a tax package and a distributed manufacturing control system. The
chapter closes:

Therefore, put all your thoughts behind this simple idea: release
little bits, to be used by real customers, very frequently. It
will enable you to deliver the most value in the shortest time,
with great confidence and low stress. We also think it will grow
new hair on your head and help you lose weight, but we're not sure
about those two. The rest -- we're sure.

Note the phrase: "real customers".

In mitigation of the sorrow we all feel for a formerly with it
colleague who has somehow run off the rails, I point out that we do in
fact use the word "release" in two senses. Release Planning, heard of
it?, is about planning to ship. We say "release code" when we mean
putting it in the repository as the main line. That kind of release we
do multiple times per day. It would have been better to have used two
different words. If we had known it would throw you off, we would
have. My apologies.

Regarding what's going on in Transition, the RUP /does not/ show zero
development in that phase. In fact, it shows a little hump, which I
gather from the text represents last minute bug fixes. (This is not a
joke, that's what it represents.) The writeup on the RUP CD explicitly
allows for features in Transition with "If, however, new features have
to be added, the iteration is similar to one in the construction phase
requiring analysis&design, etc."

One of the distinguishing features of XP, vis-a-vis RUP, is that every
XP iteration is supposed to be the same. When the customer decides to
ship CDs to users, we want her to walk over and pick up the top CD
from the integration stack, hand it to the manufacturing guy, lead us
in a quick round of quiet cheers, and let us get back to testing,
programming, and designing the features she gave us last Monday.

Yes, there are things that have to be done on the project for shipping
that wouldn't have to be done if you weren't going to ship. Someone
has to buy a stamp and make a mailing label -- or set up a shipping
facility. Those things do have to be figured out. Neither XP nor the
RUP tell you how to buy a stamp. I can't even find it in the CMM.

The difference is, now that I've pointed it out, the SEI will improve
their documentation to include stamp purchase, and Rational will put a
tool into the next version of RUP to link to www.stamps.com. XP trusts
that someone on the team can find their way to the post office or
goggle up stamps on line.

Ron Jeffries
www.XProgramming.com
Fear is the mindkiller. --Bene Gesserit Litany Against Fear


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-28 15:42:09 UTC
Permalink
Ron, thanks both for the humor and the replacement of the rails. I have
reread the chapters with your comments in mind and now believe your heart is
in the right place. I think that we will continue to disagree about whether
this "actual release" is an easy problem that is occasionally hard, or a
hard problem that is occasionally easy...

Dan ;-)
Post by Dan Rawsthorne
Post by Dan Rawsthorne
I don't see much transition phase in the XP practices. If
you use the
Post by Dan Rawsthorne
definition of Transition that UP does, then no development
happens, only
Post by Dan Rawsthorne
adaptation and bug fixes. What I see in XP is the
development of "working
Post by Dan Rawsthorne
releases" on integration machines, but not so much about
shipping software
Post by Dan Rawsthorne
to actual users. That's not a knock on XP, it's just a
statement that this
Post by Dan Rawsthorne
part of a project is outside XP's scope as currently
defined by the 12-13
Post by Dan Rawsthorne
practices...
I believe that some XP projects believe in moving from
integration machines
Post by Dan Rawsthorne
to actual users very often, but I don't see that as a
documented practice -
Post by Dan Rawsthorne
not even in your book :) What I see is that the
definition of release is
Post by Dan Rawsthorne
"make the code on the integration machine the official
version" (pink, pg
Post by Dan Rawsthorne
123). This is very cool, but there is still the transition
of this official
Post by Dan Rawsthorne
version out to users. This is precisely what UP calls the Transition
phase... it includes all the alpha, beta, etc stuff leading
up to final
Post by Dan Rawsthorne
acceptance by the user community. Since "the outermost XP
cycle is the
Post by Dan Rawsthorne
release" (pink, 49), it is clear that the cycle of moving
to the actual
Post by Dan Rawsthorne
users (transition) is outside XP's scope, at least
according to the pink
Post by Dan Rawsthorne
book :)
I do apologize for not making this clear before now, Dan. However ...
In "Small Releases", Chapter 7, the precis says
The outermost XP cycle is the release. Small and frequent releases
provide early benefit to the customer while providing early
feedback to the programmers. Here are some thoughts on how to make
it happen.
If possible, wait no more than two months to release a version of
the software, and release every couple of months thereafter. And
we don't mean a demo version; we mean an actual version that does
something useful.
(We were wimpy here. That whole every two months is way too long.)
Then it goes on to describe how we could have (and should have IMO)
released the payroll incrementally. Then ideas for a personnel system.
Then a tax package and a distributed manufacturing control system. The
Therefore, put all your thoughts behind this simple idea: release
little bits, to be used by real customers, very frequently. It
will enable you to deliver the most value in the shortest time,
with great confidence and low stress. We also think it will grow
new hair on your head and help you lose weight, but we're not sure
about those two. The rest -- we're sure.
Note the phrase: "real customers".
In mitigation of the sorrow we all feel for a formerly with it
colleague who has somehow run off the rails, I point out that we do in
fact use the word "release" in two senses. Release Planning, heard of
it?, is about planning to ship. We say "release code" when we mean
putting it in the repository as the main line. That kind of release we
do multiple times per day. It would have been better to have used two
different words. If we had known it would throw you off, we would
have. My apologies.
Regarding what's going on in Transition, the RUP /does not/ show zero
development in that phase. In fact, it shows a little hump, which I
gather from the text represents last minute bug fixes. (This is not a
joke, that's what it represents.) The writeup on the RUP CD explicitly
allows for features in Transition with "If, however, new features have
to be added, the iteration is similar to one in the construction phase
requiring analysis&design, etc."
One of the distinguishing features of XP, vis-a-vis RUP, is that every
XP iteration is supposed to be the same. When the customer decides to
ship CDs to users, we want her to walk over and pick up the top CD
from the integration stack, hand it to the manufacturing guy, lead us
in a quick round of quiet cheers, and let us get back to testing,
programming, and designing the features she gave us last Monday.
Yes, there are things that have to be done on the project for shipping
that wouldn't have to be done if you weren't going to ship. Someone
has to buy a stamp and make a mailing label -- or set up a shipping
facility. Those things do have to be figured out. Neither XP nor the
RUP tell you how to buy a stamp. I can't even find it in the CMM.
The difference is, now that I've pointed it out, the SEI will improve
their documentation to include stamp purchase, and Rational will put a
tool into the next version of RUP to link to www.stamps.com. XP trusts
that someone on the team can find their way to the post office or
goggle up stamps on line.
Ron Jeffries
www.XProgramming.com
Fear is the mindkiller. --Bene Gesserit Litany Against Fear
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 17:49:32 UTC
Permalink
Post by Dan Rawsthorne
Ron, thanks both for the humor and the replacement of the rails. I have
reread the chapters with your comments in mind and now believe your heart is
in the right place. I think that we will continue to disagree about whether
this "actual release" is an easy problem that is occasionally hard, or a
hard problem that is occasionally easy...
Well I think it's usually non-trivial and not as hard as some people
make it. And you?

Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide whether it's true for you.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Palanza
2002-08-27 14:37:00 UTC
Permalink
Post by jhrothjr
Or maybe Alexander created a way of making concrete and steel flow like
code? Somehow, I don't think so.
I can see that you have never seen a construction crew take a jack-hammer
to miss cast foundation. I would say that it is about as difficult as
fixing a poorly conceived database structure, with lots of committed code
in place.

Believe me, John, things are not what they may look like from the sidewalk.
In software the artifact is of lighter carriage, but the human issue,
particularly relative to design, are in fact identical.

Dan

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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill de hÓra
2002-08-27 14:55:20 UTC
Permalink
Post by jhrothjr
Post by jhrothjr
Or maybe Alexander created a way of making concrete and
steel flow like
Post by jhrothjr
code? Somehow, I don't think so.
I can see that you have never seen a construction crew take a
jack-hammer
to miss cast foundation.
I'm curious. Hands up how many people on this list have built a
building? Or even have used a Jackhammer on a foundation? I ask because
software and building are apples and oranges from where I'm standing.
Perhaps I'm failing to see the point of this thread.

regards,
Bill de hÓra
..
Propylon
www.propylon.com




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mike Clark
2002-08-27 20:15:13 UTC
Permalink
Post by Bill de hÓra
I'm curious. Hands up how many people on this list have built a
building?
(One hand.)
Post by Bill de hÓra
Or even have used a Jackhammer on a foundation?
(Two hands.)
Post by Bill de hÓra
I ask because
software and building are apples and oranges from where I'm standing.
Perhaps I'm failing to see the point of this thread.
I'm just thankful I'm reading this thread and not doing the aforementioned.

Mike
--
Mike Clark
Clarkware Consulting Inc.
http://www.clarkware.com
(720) 851-2014




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Palanza
2002-08-27 15:59:33 UTC
Permalink
Post by Bill de hÓra
I ask because
software and building are apples and oranges from where I'm standing.
Perhaps I'm failing to see the point of this thread.
Perhaps what you are missing is context. In a context focusing taste apples
and oranges are quite different. In a context focusing nutrition, or
design, they have much in common. Types of reasoning make context
essential. Design is a type of reasoning that occurs in the construction of
artifacts, as products of value. As such, design has commonality across all
disciplines. It makes sense, since we are all using the same type of "meat
machine" (I forgot the gentleman's name who coined this phrase) to get
favorable results.

Dan


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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill de hÓra
2002-08-27 17:38:50 UTC
Permalink
Post by Kent Beck
-----Original Message-----
Post by Bill de hÓra
Perhaps I'm failing to see the point of this thread.
Perhaps what you are missing is context.
Not really. I'm trying to understand why software folk keeping looking
to building and architecture for design understanding, when really they
have little in common.
Post by Kent Beck
Design is a type of reasoning that occurs in the
construction of
artifacts, as products of value.
Yes, so why get stuck on building? Why not typography, weapons-making or
gardening?

regards,
Bill de hÓra
..
Propylon
www.propylon.com




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
C. Keith Ray
2002-08-27 19:17:48 UTC
Permalink
Post by Bill de hÓra
Post by Kent Beck
-----Original Message-----
Post by Bill de hÓra
Perhaps I'm failing to see the point of this thread.
Perhaps what you are missing is context.
Not really. I'm trying to understand why software folk keeping looking
to building and architecture for design understanding, when really they
have little in common.
Post by Kent Beck
Design is a type of reasoning that occurs in the
construction of
artifacts, as products of value.
Yes, so why get stuck on building? Why not typography, weapons-making or
gardening?
Or making battle-plans and then executing them.

----

C. Keith Ray
<http://homepage.mac.com/keithray/resume2.html>
<http://homepage.mac.com/keithray/xpminifaq.html>



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Palanza
2002-08-27 18:00:55 UTC
Permalink
Post by Bill de hÓra
Yes, so why get stuck on building? Why not typography, weapons-making or
gardening?
I believe it happens because of the nature of the artifact. Many new ones
are built from scratch using principles that need to be held in common by a
large community of contributors, and users. Buildings are familiar to
software people, and code is familiar to builders, to name some of the
important reasons for using construction in analogy to software development.

Dan


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


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-27 19:26:18 UTC
Permalink
Post by Dan Palanza
Post by jhrothjr
Or maybe Alexander created a way of making concrete and steel flow like
code? Somehow, I don't think so.
I can see that you have never seen a construction crew take a jack-hammer
to miss cast foundation. I would say that it is about as difficult as
fixing a poorly conceived database structure, with lots of committed code
in place.
Sure they do. A couple of days after the foundation has been poured, and before the steel and other elements have been erected. That's one of the reasons for building inspectors, as far as I understand it. Building inspectors, BTW, are the same thing as code inspections.
Post by Dan Palanza
Believe me, John, things are not what they may look like from the sidewalk.
In software the artifact is of lighter carriage, but the human issue,
particularly relative to design, are in fact identical.
The whole point is that the process of constructing a major building is identical to waterfall, and for very good reasons. Mistakes made early in the process, and caught late, tend to be very, very expensive to fix. Of course, some mistakes are easier to fix than others, and some aspects of buildings are designed to be rather flexible: remodeling a floor in a modern office building is much easier than it used to be, as long as you don't exceed the floor load limits (and yes, that happened in a building I was working in.)

Your example is one of a mistake caught right away. That's the cheapest kind to fix. One building I worked in (a big, red one on the southeast side of Chicago's Loop) was delayed for well over a year when the building owners decided that they wanted the executive offices on top, where the architects had put the data center. The floors they finally put the data center on had to be extensively reinforced to take the additional load.

This kind of limitation is not necessary when you don't have major physical artifacts to deal with. Could Kufhu have changed the design of the Great Pyramid in the middle? Not likely.

John Roth
Post by Dan Palanza
Dan
[Non-text portions of this message have been removed]
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-27 00:34:06 UTC
Permalink
Post by Booch, Grady
Post by Christopher Hart
The examples also bring forward one of the failings in
communicating XP in that it is still too developer-centric.
[egb> ] But, isn't that the primary focus of XP (it's extreme <programming>
not extreme <project management>)? There are no specific best practices
therein that are directed to the project manager or other such stakeholders,
save for the issues surrounding the planning game...and that's a practice
that's not nearly at the same level of abstraction as those for the
developer (e.g. test first, pair programming)
It's not the primary focus the way I teach it. I think that the
business cycle practices: whole team / on-site customer; planning
game; small releases; customer tests; are the really important ones.

But I could be wrong.

Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dave Rooney
2002-08-27 01:03:27 UTC
Permalink
Ron,

You're right, but the fact that the executable code is the primary artifact
of an XP project leads people to believe that it's "of the programmers, by
the programmers, for the programmers". There's nothing wrong with that, but
the planning and management aspects of XP are usually overlooked by the
unwashed masses.
Post by Ron Jeffries
But I could be wrong.
In which case, it would be Chet's fault. :)

Dave Rooney
Mayford Technologies
http://www.mayford.ca


-----Original Message-----
From: Ron Jeffries [mailto:***@acm.org]
Sent: Monday, August 26, 2002 8:34 PM
To: ***@yahoogroups.com
Subject: Re: [XP] FW: Are You Getting XPed On
Post by Ron Jeffries
Post by Christopher Hart
The examples also bring forward one of the failings in
communicating XP in that it is still too developer-centric.
[egb> ] But, isn't that the primary focus of XP (it's extreme
<programming>
Post by Ron Jeffries
not extreme <project management>)? There are no specific best practices
therein that are directed to the project manager or other such
stakeholders,
Post by Ron Jeffries
save for the issues surrounding the planning game...and that's a practice
that's not nearly at the same level of abstraction as those for the
developer (e.g. test first, pair programming)
It's not the primary focus the way I teach it. I think that the
business cycle practices: whole team / on-site customer; planning
game; small releases; customer tests; are the really important ones.

But I could be wrong.

Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-27 01:12:35 UTC
Permalink
Post by Dave Rooney
You're right, but the fact that the executable code is the primary artifact
of an XP project leads people to believe that it's "of the programmers, by
the programmers, for the programmers". There's nothing wrong with that, but
the planning and management aspects of XP are usually overlooked by the
unwashed masses.
Usually? How do we know this?

Ron Jeffries
www.XProgramming.com
XP says: Don't just sit on your DUF, do something. Get some feedback.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dave Rooney
2002-08-27 03:18:51 UTC
Permalink
Ron,
Post by Ron Jeffries
Usually? How do we know this?
How many people are drawn to XP because of it's planning and management
aspects? How many are drawn to it because it allows programmers to program
without guilt?

How many come for the latter and discover the former, and think that XP
isn't just cool, it's what cool wants to be when it grows up?

Dave Rooney
Mayford Technologies
http://www.mayford.ca


-----Original Message-----
From: Ron Jeffries [mailto:***@acm.org]
Sent: Monday, August 26, 2002 9:13 PM
To: ***@yahoogroups.com
Subject: Re: [XP] FW: Are You Getting XPed On
Post by Ron Jeffries
You're right, but the fact that the executable code is the primary artifact
of an XP project leads people to believe that it's "of the programmers, by
the programmers, for the programmers". There's nothing wrong with that, but
the planning and management aspects of XP are usually overlooked by the
unwashed masses.
Usually? How do we know this?

Ron Jeffries
www.XProgramming.com
XP says: Don't just sit on your DUF, do something. Get some feedback.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-27 03:41:21 UTC
Permalink
Post by Dave Rooney
Post by Ron Jeffries
Usually? How do we know this?
How many people are drawn to XP because of it's planning and management
aspects? How many are drawn to it because it allows programmers to program
without guilt?
How many come for the latter and discover the former, and think that XP
isn't just cool, it's what cool wants to be when it grows up?
Good questions ... but what are the answers? And how many teams do XP
without learning the whole thing, trying the planning stuff? I don't
know.

Ron Jeffries
www.XProgramming.com
You are closing your eyes to a situation you do not wish to acknowledge.
--Professor Harold Hill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Rob Sartin
2002-08-26 21:42:21 UTC
Permalink
Post by Dave Rooney
How many people are drawn to XP because of it's planning and management
aspects? How many are drawn to it because it allows programmers to program
without guilt?
Anecdotal response:

I came for the planning and stayed because I found the practices created a
more effective team. My observation of real projects had long led me to
believe that the whole notion of a priori requirements gathering, analysis,
and design, simply did not work. I was attracted by a process that did not
require, or even suggest, that requirements froze and all design should be
done before coding. I was also attracted by the notion of frequent releases
and a code base that was always complete and ready to release if schedule
and demands of the day required it. To me, this is a planning distinction,
and that is how I've always pitched it to management.

I suppose we could have a poll....

Regards,

Rob


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-26 15:08:51 UTC
Permalink
Post by Dan Palanza
In building construction we call a project manager the "general
contractor." I've been curiously waiting to see this contributor jell in
the XP philosophy, complementary to customer and separate from
implementation craft contributors, such as programmers and the overall
project design. In my attempts to do agile construction we get customer
versus contractor and craft-contributors versus design-team.
Craft-contributor and design-team both affect architecture but in
different
ways. I don't see a way to reduce a balanced team below four such
categories, whatever one decides to name them.
[egb> ] Following up on your thread, I'd suggest a best practice for such
folks to be something like "Attack risks intentionally" which translates (at
least in the RUP world view) to a) intentionally identifying the technical,
economic, and business risks to the project at hand, b) making those risks
visible to all the stakeholders, c) using these risks to drive the activity
of each iteration and then d) revisiting these risks at each iteration

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Pollice, Gary
2002-08-26 18:26:15 UTC
Permalink
Ron,

I understand your concern, but I have a little bit different view. In a
perfect world, people should be able to try pure XP and learn about it and
then decide whether they can use it or just adopt some of the practices in
their organization. But we don't live in a perfect world. So, my feeling is
that I'd rather have someone try to do just one of the practices if they
think it would help them. Then maybe they'll do some more. Perhaps they'll
even find new ways of doing things.

We find this a lot with RUP. People say they're using RUP and they fail and
blame RUP. Then we look at what they're doing and find that they're either
trying to do all of the things in the RUP framework (never a good idea), or
just doing things wrong (e.g., use use cases for functional decomposition).
It's a learning experience. If they want to blame RUP, that's okay as long
as they give us a chance to come in and help them understand what's going
wrong and help them, or find that RUP isn't a fit for them. I just don't
want them blaming me personally. I draw the line there. :-)

Actually, many of our customers are very interested in the new XP Plug-In,
but they want to use it with other RUP configurations. I suspect we will
need two ways of presenting the content: pure XP, and a derivative that lets
them mix and match. If I believe that they are intelligent people (and I do
believe that) then I have to trust them to be self-organizing and
self-directing.

--Gary

-----Original Message-----
From: Ron Jeffries
To: ***@yahoogroups.com
Sent: 8/26/2002 4:11 AM
Subject: Re: [XP] FW: Are You Getting XPed On

...

I share the concern that XP will be watered down, and the name
misused. I know of projects where, in my opinion, this is going on
right now. What to do? I don't know.

...

Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-27 01:11:04 UTC
Permalink
Post by Pollice, Gary
I understand your concern, but I have a little bit different view. In a
perfect world, people should be able to try pure XP and learn about it and
then decide whether they can use it or just adopt some of the practices in
their organization. But we don't live in a perfect world. So, my feeling is
that I'd rather have someone try to do just one of the practices if they
think it would help them. Then maybe they'll do some more. Perhaps they'll
even find new ways of doing things.
Certainly one would hope that. What concerns me isn't so much teams
that forget to try pair programming as it is management who forgets to
use scope control. There are some approaches that are just not agile,
and it troubles me to see the method so warped.
Post by Pollice, Gary
We find this a lot with RUP. People say they're using RUP and they fail and
blame RUP. Then we look at what they're doing and find that they're either
trying to do all of the things in the RUP framework (never a good idea), or
just doing things wrong (e.g., use use cases for functional decomposition).
It's a learning experience. If they want to blame RUP, that's okay as long
as they give us a chance to come in and help them understand what's going
wrong and help them, or find that RUP isn't a fit for them. I just don't
want them blaming me personally. I draw the line there. :-)
That's why we have Chet ...
Post by Pollice, Gary
Actually, many of our customers are very interested in the new XP Plug-In,
but they want to use it with other RUP configurations. I suspect we will
need two ways of presenting the content: pure XP, and a derivative that lets
them mix and match. If I believe that they are intelligent people (and I do
believe that) then I have to trust them to be self-organizing and
self-directing.
If intelligence were all it takes, we'd be all set. Unfortunately,
there are things that can't be reached by pure reason, and I think
that some key aspects of agile processes are in that space.

Ron Jeffries
www.XProgramming.com
Curiosity is more powerful than skepticism.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Steve Ropa
2002-08-26 21:37:17 UTC
Permalink
Gary,
Post by Kent Beck
-----Original Message-----
Sent: Monday, August 26, 2002 12:26 PM
Subject: RE: [XP] FW: Are You Getting XPed On
We find this a lot with RUP. People say they're using RUP and
they fail and
blame RUP. Then we look at what they're doing and find that
they're either
trying to do all of the things in the RUP framework (never a
good idea), or
just doing things wrong (e.g., use use cases for functional
decomposition).
It's a learning experience. If they want to blame RUP, that's
okay as long
as they give us a chance to come in and help them understand
what's going
wrong and help them, or find that RUP isn't a fit for them. I
just don't
want them blaming me personally. I draw the line there. :-)
I can attest to that experience. I had done RUP "by the book" to the best of my ability, even to the point of hiring you guys to come in and teach it to the whole team. In all honesty, as I have said before, the guy who was teaching the class *really* pushed that you had to do EVERYTHING or it woudn't work. We spent so much time trying to do EVERYTHING that we ended up doing NOTHING. Its nice to see that you are not pushing that line. Hopefully, the whole company is getting that message.

I also was inclined to blame RUP. It actually wasn't until I started defending XP with the idea that perhaps those who were blaming XP should be looking a little closer at themselves that I realize I had done the same thing to RUP. Not that I would go back, mind you... :-)

Steve

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-27 05:18:20 UTC
Permalink
Post by Dave Rooney
You're right, but the fact that the executable code is the primary
artifact
of an XP project
[egb> ] executable code is the primary artifact of <any> software-intensive
project....it's just that some development cultures - particular those who
are afraid of code - bury these executables among a continent of secondary
and tertiary artifacts such that it produces the misguided illusion that
perhaps running code is not so critical after all...

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-27 05:31:31 UTC
Permalink
Post by Booch, Grady
Post by Dave Rooney
You're right, but the fact that the executable code is the primary
artifact
of an XP project
[egb> ] executable code is the primary artifact of <any> software-intensive
project....it's just that some development cultures - particular those who
are afraid of code - bury these executables among a continent of secondary
and tertiary artifacts such that it produces the misguided illusion that
perhaps running code is not so critical after all...
Entirely serious question, Grady: why does the RUP make this point so
difficult to see? As you probably know, I've been looking at it
moderately hard, and what you've said there isn't exactly jumping out
at me.

Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide whether it's true for you.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dave Rooney
2002-08-27 09:41:20 UTC
Permalink
Grady,

Agreed - the thought that other methodologies seem to minimize the
importance of the running system where XP maximizes it was precisely my
point.

Dave Rooney
Mayford Technologies
http://www.mayford.ca


-----Original Message-----
From: Booch, Grady [mailto:***@rational.com]
Sent: Tuesday, August 27, 2002 1:18 AM
To: '***@yahoogroups.com'
Subject: RE: [XP] FW: Are You Getting XPed On
Post by Dave Rooney
You're right, but the fact that the executable code is the primary
artifact
of an XP project
[egb> ] executable code is the primary artifact of <any> software-intensive
project....it's just that some development cultures - particular those who
are afraid of code - bury these executables among a continent of secondary
and tertiary artifacts such that it produces the misguided illusion that
perhaps running code is not so critical after all...

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-27 13:36:55 UTC
Permalink
Post by jhrothjr
In XP, the result of design is, in fact, the final system the customer
wanted. There is no separate design phase that simply produces paper that
the construction process uses.
[egb> ] Kent and I debated this point at the CTO Forum. I acknowledge that
in XP (and in the RUP) one grows an architecture. But where do architectural
decisions lie in XP, decision such as "let's use J2EE" or even more
fundamental ones such as "let's expose the functionality of this system via
a web interface?" Often, because of the context of an XP project, these
things seem to be givens, part of the atmosphere. However, there are indeed
significant design decisions (oh, we've laid down all this code, and now we
need to do it in C#...that'll cost; oh, we don't want to push this out on
the web because of security issues? Ah, that will introduce some changes as
well...).

In the RUP, the elaboration phase makes and validates such significant
design decisions (all architecture is design, not all design is
architecture)...and validates them not through paper but through the
delivery of executables.

In that sense, I think therefore we are likely saying the same things: there
exist early iterations that make and validate these architectural decisions
and then, in successive iterations, grows this architecture (but certainly
permits changing such decisions, recognizing that there is indeed a cost of
change).

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-27 13:54:57 UTC
Permalink
Post by Booch, Grady
In that sense, I think therefore we are likely saying the same things: there
exist early iterations that make and validate these architectural decisions
and then, in successive iterations, grows this architecture (but certainly
permits changing such decisions, recognizing that there is indeed a cost of
change).
Yes. In XP there are decisions. They aren't called out as milestones,
and they aren't delineated into phases. But there are decisions.

Ron Jeffries
www.XProgramming.com
Curiosity is more powerful than skepticism.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-27 15:04:39 UTC
Permalink
Post by Booch, Grady
Post by jhrothjr
In XP, the result of design is, in fact, the final system the customer
wanted. There is no separate design phase that simply produces paper that
the construction process uses.
[egb> ] Kent and I debated this point at the CTO Forum. I acknowledge that
in XP (and in the RUP) one grows an architecture. But where do architectural
decisions lie in XP, decision such as "let's use J2EE" or even more
fundamental ones such as "let's expose the functionality of this system via
a web interface?" Often, because of the context of an XP project, these
things seem to be givens, part of the atmosphere. However, there are indeed
significant design decisions (oh, we've laid down all this code, and now we
need to do it in C#...that'll cost; oh, we don't want to push this out on
the web because of security issues? Ah, that will introduce some changes as
well...).
In the RUP, the elaboration phase makes and validates such significant
design decisions (all architecture is design, not all design is
architecture)...and validates them not through paper but through the
delivery of executables.
In that sense, I think therefore we are likely saying the same things: there
exist early iterations that make and validate these architectural decisions
and then, in successive iterations, grows this architecture (but certainly
permits changing such decisions, recognizing that there is indeed a cost of
change).
Now, that's a very, very significant observation, and not just on the XP versus RUP debate, or whatever. If we think of where we've been with software engineering in the last however many years, one of the common threads has been how to write software so that all the hard to change lumps are not there. XP does this reasonably well, but as you point out, there are still some up front decisions that are going to cause you massive pain to change.

Once I've decided on Java versus C++ for my server, or VB versus Python for my client, I'm going to have a very large cost to change. And what does the lockin decision buy me? Very, very little, in fact. It's a completely artificial barrier to change, as opposed to pouring concrete and erecting steel when you're constructing a real building.

So maybe up front architecture isn't a real issue at all in the long term? It is something that's forced on us by the current competitive, product distinguishing business climate, and will go away when people realize what it's costing them, and take action?

John Roth


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Georg Tuparev
2002-08-27 22:04:24 UTC
Permalink
Post by jhrothjr
Once I've decided on Java versus C++ for my server, or VB versus Python
for my client, I'm going to have a very large cost to change.
Why do you think so?

Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-28 12:15:12 UTC
Permalink
Post by Georg Tuparev
Post by jhrothjr
Once I've decided on Java versus C++ for my server, or VB versus Python
for my client, I'm going to have a very large cost to change.
Why do you think so?
Do you know of an application that will automatically convert a complete system in one language to another language? Understanding all of the nuances that make sense in one language which don't in another, converting them properly, and identifying the things that can be done more easily in the new language and doing that?

I know of applications that claim to be able to do some of that, but their results have all the beauty of C++ written by COBOL programmers.

John Roth
Post by Georg Tuparev
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
C. Keith Ray
2002-08-28 14:16:57 UTC
Permalink
Post by jhrothjr
Post by Georg Tuparev
Post by jhrothjr
Once I've decided on Java versus C++ for my server, or VB versus Python
for my client, I'm going to have a very large cost to change.
Why do you think so?
Do you know of an application that will automatically convert a complete
system in one language to another language? Understanding all of the nuances
that make sense in one language which don't in another, converting them
properly, and identifying the things that can be done more easily in the new
language and doing that?
I heard that, <sarcasm> by some strange coincidence </sarcasm>, Java code
can be translated to C# code programmatically with 100% semantic fidelity.

----

C. Keith Ray
<http://homepage.mac.com/keithray/resume2.html>
<http://homepage.mac.com/keithray/xpminifaq.html>



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dhemeryy
2002-08-28 15:40:21 UTC
Permalink
Hi John,
Post by jhrothjr
Do you know of an application that will automatically convert a
complete system in one language to another language?
A compiler.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Steve Ropa
2002-08-27 14:08:24 UTC
Permalink
Hi Dave,
Post by Kent Beck
-----Original Message-----
Sent: Monday, August 26, 2002 9:19 PM
Subject: RE: [XP] FW: Are You Getting XPed On
Ron,
Post by Ron Jeffries
Usually? How do we know this?
How many people are drawn to XP because of it's planning and
management
aspects? How many are drawn to it because it allows
programmers to program
without guilt?
But I was drawn to XP for both reasons. I really wasn't convinced about XP being anything except a "license to hack" until I studied the planning and management aspects. When I figured out that this was a methodology that would give me the ability to manage fellow programmers, without trying to force them to jump through hoops that don't feel natural, I was hooked. The fact that the primary activity of XP is programming makes my job as a manager easier, because I get to let the programmers do what they want to do. However, that would be for naught if I couldn't proved satisfaction to the customers.

However, I will state that my personal experience has been that most people are drawn to the programming aspect, and the managerial is either a bonus or the part that they totally ignore, more's the pity.

Steve

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-27 23:21:32 UTC
Permalink
Post by jhrothjr
Once I've decided on Java versus C++ for my server, or VB versus Python
for my client, I'm going to have a very large cost to change. And what
does the lockin decision buy me? Very, very little, in fact. It's a
completely artificial barrier to change, as opposed to pouring concrete
and erecting steel when you're constructing a real building.
[egb> ] And thus the basic of the schism between the two great platform
religions of the world: many languages/one platform or one language/many
platforms.
Post by jhrothjr
So maybe up front architecture isn't a real issue at all in the long term?
It is something that's forced on us by the current competitive, product
distinguishing business climate, and will go away when people realize what
it's costing them, and take action?
[egb> ] Unless you are a Sun, IBM, Microsoft, or Oracle (and so on), you
don't have any control over the platforms upon which you build. Insofar as
those platforms raise the level of abstraction upon which you build a
system, good (do you really want to write a middleware messaging system from
scratch? You used to have to do that....); insofar as those platforms lock
you in and form a large inertial mass that resists change, bad. However,
note that upfront architecture is a factor not just of the major platforms,
but also of the legacy that organizations create. If I just spent a few tens
of millions to deploy an app to all the tellers in all my banks, for
example, that's in effect a platform that I created. Insofar as that legacy
is resilient, good; insofar as it resists change, then bad...for one can
rarely start from scratch, due to the capital investment made in that
legacy.

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ellen Ferlazzo
2002-08-28 03:27:27 UTC
Permalink
Grady,

I see you are speaking at the SD Forum on Sep 12. I'm quite looking
forward to hearing you, after having enjoyed your many posts on the XP
group.

My contract at SourceForge / VA Software is nearing an end and it's been
great fun. But I've put off the article I promised Rebecca Bence at
Rational for too long so it will be good to have some writing time as
well.

Ellen Ferlazzo
software designer / writer
www.sprez.com



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ellen Ferlazzo
2002-08-28 03:42:07 UTC
Permalink
Sorry about that... Meant to be a "reply" but the group is set to reply
to the group.

Ellen Ferlazzo
software designer / writer
www.sprez.com
Post by Kent Beck
-----Original Message-----
Sent: Tuesday, August 27, 2002 8:27 PM
Subject: [XP] -- but really Software Developer's Forum
Grady,
I see you are speaking at the SD Forum on Sep 12. [...]
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-28 12:19:22 UTC
Permalink
Post by Booch, Grady
Post by jhrothjr
Once I've decided on Java versus C++ for my server, or VB versus Python
for my client, I'm going to have a very large cost to change. And what
does the lockin decision buy me? Very, very little, in fact. It's a
completely artificial barrier to change, as opposed to pouring concrete
and erecting steel when you're constructing a real building.
[egb> ] And thus the basic of the schism between the two great platform
religions of the world: many languages/one platform or one language/many
platforms.
Post by jhrothjr
So maybe up front architecture isn't a real issue at all in the long term?
It is something that's forced on us by the current competitive, product
distinguishing business climate, and will go away when people realize what
it's costing them, and take action?
[egb> ] Unless you are a Sun, IBM, Microsoft, or Oracle (and so on), you
don't have any control over the platforms upon which you build. Insofar as
those platforms raise the level of abstraction upon which you build a
system, good (do you really want to write a middleware messaging system from
scratch? You used to have to do that....); insofar as those platforms lock
you in and form a large inertial mass that resists change, bad. However,
note that upfront architecture is a factor not just of the major platforms,
but also of the legacy that organizations create. If I just spent a few tens
of millions to deploy an app to all the tellers in all my banks, for
example, that's in effect a platform that I created. Insofar as that legacy
is resilient, good; insofar as it resists change, then bad...for one can
rarely start from scratch, due to the capital investment made in that
legacy.
Very well said. And one of the major challenges facing us, as a profession, is to remove as much of the resistance to change as possible.

John Roth


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-28 02:27:23 UTC
Permalink
Either you are off the rails or I'm not getting your point. There are
a million things not specified in XP. If the customer wants it, the
customer asks for it. The programmers do it.
[egb> ] Sometimes the customer is not always right; sometimes you don't need
more software, you need less. This is why I argue that delivering a
software-intensive system is not a simply matter of programming, of looking
at the process simply as one of cutting beautiful code. A reasonable process
has to drive its iterations by considering functionality, risks, business,
AND economic contexts, not just a simple reaction to customer desires. You
might suggest that this is all wrapped up in XP's planning game, and I'd
probably agree with you. I'd also agree with you that, especially therein,
there are a million things not specified by XP.

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 03:15:29 UTC
Permalink
Post by Booch, Grady
Either you are off the rails or I'm not getting your point. There are
a million things not specified in XP. If the customer wants it, the
customer asks for it. The programmers do it.
[egb> ] Sometimes the customer is not always right; sometimes you don't need
more software, you need less. This is why I argue that delivering a
software-intensive system is not a simply matter of programming, of looking
at the process simply as one of cutting beautiful code.
Yes, right. That's probably why no one I know suggests that delivering
a software-intensive system is simply a matter of programming or of
looking at the process simply as one of cutting beautiful code.
Post by Booch, Grady
A reasonable process
has to drive its iterations by considering functionality, risks, business,
AND economic contexts, not just a simple reaction to customer desires. You
might suggest that this is all wrapped up in XP's planning game, and I'd
probably agree with you.
Yes, all those things must be considered. In XP, the customer makes
the business decision of what to build and when to build it based on
business value, risk, cost of the build, etc, I might call that
"customer desires" and I certainly wouldn't call it "simple".
Post by Booch, Grady
I'd also agree with you that, especially therein,
there are a million things not specified by XP.
Right. The focus of XP is to specify the minimum. It probably goes
overboard anyway, specifying too much. Maybe Alistair's Crystal Clear
is right. ;->

Ron Jeffries
www.XProgramming.com
You do ill if you praise, but worse if you censure,
what you do not understand. --Leonardo da Vinci


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Pierre Boudreau
2002-08-28 12:48:31 UTC
Permalink
Post by Ron Jeffries
Yes, all those things must be considered. In XP, the customer makes
the business decision of what to build and when to build it based on
business value, risk, cost of the build, etc, I might call that
"customer desires" and I certainly wouldn't call it "simple".
Post by Booch, Grady
I'd also agree with you that, especially therein,
there are a million things not specified by XP.
Right. The focus of XP is to specify the minimum. It probably goes
overboard anyway, specifying too much. Maybe Alistair's Crystal Clear
is right. ;->
Could this be exactly the reason people are getting XPed on? It's easy for
you to know that all those things must be considered, but is it obvious to
someone who reads 1 or 2 books and tries to go out and "do XP". Does the
lack of specifications for the methodology make it look easy and tempting
for people to try it without knowing how hard it is? Specifyng the minimum
might work if you have a Ron Jefferies on your team with all that knowledge
and experience in his head, but does it work for other teams? I guess
that's what you said when you said that your experiences are biassed by
being _your_ experiences.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-28 14:51:16 UTC
Permalink
Post by Pierre Boudreau
Post by Ron Jeffries
Yes, all those things must be considered. In XP, the customer makes
the business decision of what to build and when to build it based on
business value, risk, cost of the build, etc, I might call that
"customer desires" and I certainly wouldn't call it "simple".
Post by Booch, Grady
I'd also agree with you that, especially therein,
there are a million things not specified by XP.
Right. The focus of XP is to specify the minimum. It probably goes
overboard anyway, specifying too much. Maybe Alistair's Crystal Clear
is right. ;->
Could this be exactly the reason people are getting XPed on? It's easy for
you to know that all those things must be considered, but is it obvious to
someone who reads 1 or 2 books and tries to go out and "do XP". Does the
lack of specifications for the methodology make it look easy and tempting
for people to try it without knowing how hard it is? Specifyng the minimum
might work if you have a Ron Jefferies on your team with all that knowledge
and experience in his head, but does it work for other teams? I guess
that's what you said when you said that your experiences are biassed by
being _your_ experiences.
It's difficult to learn anything from a book. Your prior experiences get in the way, and you interpret things through the filter of those experiences.

One of the most enlightening experiences I ever had was to give the exact same presentation every day for two weeks in a row. It wasn't, in fact, the same presentation. After every one, I evaluated what I did, and the questions I got asked. By the end, that presentation had been almost totally revamped, and there were very few questions, but there was a great deal more understanding.

You don't get that chance with a book. It's a classic example of up front development. If you're very lucky, you've got a small group of readers and a good, professional editor. And that's it.

Could I have learned it from the books? I'd have to say no. Much of what I know about it has come with interacting with Ron and Bob on the newsgroup and now the mailing list. The best the books managed to do was give me a coherent set of reasons behind things, and that only made sense because I knew what Kent was talking about when he brought up things like feedback.

John Roth


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Bill de hÓra
2002-08-28 17:15:50 UTC
Permalink
Post by jhrothjr
You don't get that chance with a book. It's a classic example
of up front development. If you're very lucky, you've got a
small group of readers and a good, professional editor. And that's it.
You do (did), (are), if you’re Kent Beck and your book is about Test
Driven Development :)

regards,
Bill de hÓra
..
Propylon
www.propylon.com




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Kay A. Pentecost
2002-08-28 17:29:50 UTC
Permalink
Hi, John,
Post by Kent Beck
-----Original Message-----
Sent: Wednesday, August 28, 2002 10:51 AM
Subject: Re: [XP] FW: Are You Getting XPed On
<snip>
Post by Kent Beck
You don't get that chance with a book. It's a classic example of
up front development. If you're very lucky, you've got a small
group of readers and a good, professional editor. And that's it.
Could I have learned it from the books? I'd have to say no. Much
of what I know about it has come with interacting with Ron and
Bob on the newsgroup and now the mailing list. The best the books
managed to do was give me a coherent set of reasons behind
things, and that only made sense because I knew what Kent was
talking about when he brought up things like feedback.
I've been wanting to say, somewhere, how much more valuable taking the
workshop was than reading the books. And I got a *lot* from reading the
books, and from this list, and from direct exchanges with XPers...

But actually *doing* XP -- even if it was "just" a workshop -- was
mind-boggling.

Think about *reading* about a wonderful dinner... then actually having one.

Kay
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dossy
2002-08-28 14:59:51 UTC
Permalink
I have to say, Pierre's message (as well as the bits that were quoted
from Grady and Ron) has been one of the most valuable messages to me (if
not the most valuable) of this thread.

Thanks,

-- Dossy
Post by Pierre Boudreau
Post by Ron Jeffries
Yes, all those things must be considered. In XP, the customer makes
the business decision of what to build and when to build it based on
business value, risk, cost of the build, etc, I might call that
"customer desires" and I certainly wouldn't call it "simple".
Post by Booch, Grady
I'd also agree with you that, especially therein,
there are a million things not specified by XP.
Right. The focus of XP is to specify the minimum. It probably goes
overboard anyway, specifying too much. Maybe Alistair's Crystal Clear
is right. ;->
Could this be exactly the reason people are getting XPed on? It's easy for
you to know that all those things must be considered, but is it obvious to
someone who reads 1 or 2 books and tries to go out and "do XP". Does the
lack of specifications for the methodology make it look easy and tempting
for people to try it without knowing how hard it is? Specifyng the minimum
might work if you have a Ron Jefferies on your team with all that knowledge
and experience in his head, but does it work for other teams? I guess
that's what you said when you said that your experiences are biassed by
being _your_ experiences.
--
Dossy Shiobara mail: ***@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dave Rooney
2002-08-28 17:44:03 UTC
Permalink
Dossy,

I agree... leave it to a Canadian to say it right! :)

What Pierre wrote captures the essence of what I have said before about
'assumed competence' on the part of the developers. People like Kent, Ron,
Uncle Bob, Martin, Scott, et al have forgotten more than some people will
ever know about OO development, and that fact might be lost a bit.

I'm pretty good at this software thing, but there are days where I need a
dictionary just to figure out how to spell UML! :) I would welcome
certainly a 'minimal' XP implementation guideline.

Dave Rooney
Mayford Technologies
http://www.mayford.ca


-----Original Message-----
From: Dossy [mailto:***@panoptic.com]
Sent: Wednesday, August 28, 2002 11:00 AM
To: ***@yahoogroups.com
Subject: Re: [XP] FW: Are You Getting XPed On


I have to say, Pierre's message (as well as the bits that were quoted
from Grady and Ron) has been one of the most valuable messages to me (if
not the most valuable) of this thread.

Thanks,

-- Dossy
Post by Pierre Boudreau
Post by Ron Jeffries
Yes, all those things must be considered. In XP, the customer makes
the business decision of what to build and when to build it based on
business value, risk, cost of the build, etc, I might call that
"customer desires" and I certainly wouldn't call it "simple".
Post by Booch, Grady
I'd also agree with you that, especially therein,
there are a million things not specified by XP.
Right. The focus of XP is to specify the minimum. It probably goes
overboard anyway, specifying too much. Maybe Alistair's Crystal Clear
is right. ;->
Could this be exactly the reason people are getting XPed on? It's easy for
you to know that all those things must be considered, but is it obvious to
someone who reads 1 or 2 books and tries to go out and "do XP". Does the
lack of specifications for the methodology make it look easy and tempting
for people to try it without knowing how hard it is? Specifyng the minimum
might work if you have a Ron Jefferies on your team with all that knowledge
and experience in his head, but does it work for other teams? I guess
that's what you said when you said that your experiences are biassed by
being _your_ experiences.
--
Dossy Shiobara mail: ***@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
William Pietri
2002-08-28 16:21:49 UTC
Permalink
Post by Pierre Boudreau
Post by Ron Jeffries
Post by Booch, Grady
I'd also agree with you that, especially therein,
there are a million things not specified by XP.
Right. The focus of XP is to specify the minimum. It probably goes
overboard anyway, specifying too much. Maybe Alistair's Crystal Clear
is right. ;->
Could this be exactly the reason people are getting XPed on? It's easy for
you to know that all those things must be considered, but is it obvious to
someone who reads 1 or 2 books and tries to go out and "do XP". Does the
lack of specifications for the methodology make it look easy and tempting
for people to try it without knowing how hard it is? Specifyng the minimum
might work if you have a Ron Jefferies on your team with all that knowledge
and experience in his head, but does it work for other teams? I guess
that's what you said when you said that your experiences are biassed by
being _your_ experiences.
Imagine you are trying to teach somebody to ride a bike. But they have
never seen a bike being ridden before, and you can only send them things
on paper.

You could a) send them hundreds upon hundreds of pages describing the
physics behind rotational inertia, traffic laws, maneuvering technique,
and so on. Or b) send them a short note that describes the rough way to
do it ("sit on the seat, grab the handlebars, use your feet to push on
the pedals, try not to hit things or fall over"), tell them that going
faster is easier than going slower, and give them a few tricks to
improve their balance. Then, if they really have problems, they can
write you back about the particular problem.


I think this list demonstrates that no matter how much you write about a
topic, people will still have questions that you haven't covered in
writing. And once you have more than a small amount of written material,
most people won't read it all anyhow.

The important thing is that people learn what it feels like to be riding
smoothly, and what starting to fall over feels like. So many developers,
metaphorically, have only had the experience of falling over every few
feet. They way I figure it, the less they have to keep in their heads
while developing their sense of balance, the better.


William
--
brains for sale: http://scissor.com/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 17:53:07 UTC
Permalink
Post by William Pietri
You could a) send them hundreds upon hundreds of pages describing the
physics behind rotational inertia, traffic laws, maneuvering technique,
and so on. Or b) send them a short note that describes the rough way to
do it ("sit on the seat, grab the handlebars, use your feet to push on
the pedals, try not to hit things or fall over"), tell them that going
faster is easier than going slower, and give them a few tricks to
improve their balance. Then, if they really have problems, they can
write you back about the particular problem.
Sweet metaphor!

Ron Jeffries
www.XProgramming.com
You are closing your eyes to a situation you do not wish to acknowledge.
--Professor Harold Hill


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Pierre Boudreau
2002-08-28 18:03:23 UTC
Permalink
Post by William Pietri
Imagine you are trying to teach somebody to ride a bike. But they have
never seen a bike being ridden before, and you can only send them things
on paper.
You could a) send them hundreds upon hundreds of pages describing the
physics behind rotational inertia, traffic laws, maneuvering technique,
and so on. Or b) send them a short note that describes the rough way to
do it ("sit on the seat, grab the handlebars, use your feet to push on
the pedals, try not to hit things or fall over"), tell them that going
faster is easier than going slower, and give them a few tricks to
improve their balance. Then, if they really have problems, they can
write you back about the particular problem.
Don't forget to tell them that they WILL fall several times unless they have
training wheels (coach). And don't let them borrow your million dollar,
collectors edition, bike for a while.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 02:27:50 UTC
Permalink
Post by Ron Jeffries
Sorry, I think this is incorrect. XP is all Transition Phase. You're
supposed to SHIP it.
[egb> ] I don't agree, assuming that you are using the RUP meaning of
transition (and if we had a metamodel of the two processes, we could reason
about their semantics...but that's another topic of discussion, methinks).
I am using the RUP meaning of transition. The point of XP is to put
the system into transition ASAP, then keep it that way.
Even in XP, not every release has functionality that's sufficiently above
the bar to be considered an operational system, a system that you can run
your business on (or some part of it). That state change - from under
development to operational - is what distinguishes the iterations that are
part of construction (growing the architecture) from iterations that are
part of deployment (responding to change in the operational environment),
again using RUP terminology. The reason I call this a state change is
because, in most cases, you've got a fundamentally different economic and
business context for each, with each supporting a different tolerance of
change.
Yes, I understand that that is what the RUP teaches. What XP is trying
to teach is to ship early and often, all the way to end users where it
can be, and in any case to have the system fully ready to ship every
day. That's what "Continuous Integration" really means.

Does everyone manage to do that? Certainly not. But that's the idea,
nonetheless. I am not making this up.

Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve. --ELO


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-28 02:43:58 UTC
Permalink
Post by Ron Jeffries
Yes, I understand that that is what the RUP teaches. What XP is trying
to teach is to ship early and often, all the way to end users where it
can be, and in any case to have the system fully ready to ship every
day. That's what "Continuous Integration" really means.
[egb> ] The RUP also teaches a team to ship early and often, and to engage
all the appropriate stakeholders at each iteration (in the RUP, the customer
is just one category of stakeholder in any interesting system). However,
there's a vast difference between "having the system fully ready to ship
every day" and "actually shipping the system" and that is what distinguishes
construction and transition.

[egb> ] For example, at Rational, we continuously integrate all of our
products; I daily get a dashboard status of our each suite release. There
comes a point in time where we make the business decision to say "ship it"
and then all sorts of things get lined up. It's that state change that
demarks construction and transition.

[egb> ] Now, you may argue that that's a narrow example, because it's sort
of a shrink wrap system. Ok, turn to software that runs the electrical grid
in the northeast (a project I'm engaged on). At every moment, that's a
shipped system; bits of it change a different rates of speed. However, as
the team imposes a new architecture on the grid, there's a clear point in
time we can say "this stuff is still under construction" and "it's now part
of the operational grid" The risk is too high to ship a system every day.
Furthermore, there is a limit to the ability of the system's stakeholders to
absorb change, and having these shipping events permits the other social
rhythms in the organization to synch with the software.

[egb> ] If you are talking about a relatively simple, Web-centric system
with lots of anonymous users, well, sure, ship every day, more often if you
wish. However, in my experience, for anything but the simplest system, you
cannot nor should not ship every day (but you should be ready to). The
former is the construction/transition demarcation; the latter is continuous
integration. The RUP believes in continuous integration, but it also
believes that there's a difference in being ready to ship/shipping.
Post by Ron Jeffries
But that's the idea, nonetheless. I am not making this up.
[egb> ] I never suggested that you were....

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-28 04:34:54 UTC
Permalink
Post by Dan Rawsthorne
Bingo! My point exactly. This is the project's problem, but not
addressed by
Post by Dan Rawsthorne
the XP practices... they must be solved by using something else. The XP
practices stop short of actually pouring the concrete at the actual
user's
Post by Dan Rawsthorne
site. By definition, XP stops with "it works on our integration machine,
where 'works' means it does what our Customer told us..." This is a far
cry
Post by Dan Rawsthorne
from "it works on all our user's machines, and they're all happy with
it..."
Either you are off the rails or I'm not getting your point. There are
a million things not specified in XP. If the customer wants it, the
customer asks for it. The programmers do it. The "by definition" quote
is incorrect. You'll not find that definition in any of the XP books
or in the mouths of any experienced XPer. The system is done when the
customer is happy.
Ron, Ron, Ron... You know I'm on your side, and that I love XP for what it
does. However, it doesn't do everything. And I'm going to have to use the
pink book as my reference here. The book says:
1. "the outermost XP cycle is the release"(pg 49)
2. that the release process ends when you "make the code on the
integration machine the official version" (pg 123)

Now, I had to look these up, but I certainly believe that they are virtually
identical with my "by definition" quote above. And I think that the writer
of the pink book is acknowledged as an experienced XPer, right? :) What it
boils down to is that the Customer is a role, XP provides satisfactory
service to this Customer, but this Customer may or may not know what the
actual users need. It is the Customer's job to find this stuff out, and this
process of finding out is outside the scope of the XP practices. We have
already agreed on this in previous threads, so I don't know what the problem
is with my restatement. All I have added is the statement that it is the
Customer's job to transition the working release to the user's environment
(of course, he could make stories about it, but they wouldn't be development
stories...), and that is what corresponds to the UP's transition phase.

Dan ;-)



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 11:45:38 UTC
Permalink
Post by Dan Rawsthorne
Now, I had to look these up, but I certainly believe that they are virtually
identical with my "by definition" quote above. And I think that the writer
of the pink book is acknowledged as an experienced XPer, right? :)
Asked and answered, with clear quotes from that chapter. Don't f2k
with the Phantom.
Post by Dan Rawsthorne
What it
boils down to is that the Customer is a role, XP provides satisfactory
service to this Customer, but this Customer may or may not know what the
actual users need.
It is of course the case that whoever is providing "requirements" to
the team may be providing bad requirements. Even the RUP cannot
prevent this from happening.
Post by Dan Rawsthorne
It is the Customer's job to find this stuff out, and this
process of finding out is outside the scope of the XP practices.
Yes, as is the process of finding out whether String class uses
Length, Size, or Count to say how long the string is.
Post by Dan Rawsthorne
We have
already agreed on this in previous threads, so I don't know what the problem
is with my restatement. All I have added is the statement that it is the
Customer's job to transition the working release to the user's environment
(of course, he could make stories about it, but they wouldn't be development
stories...), and that is what corresponds to the UP's transition phase.
The problem is that the restatement is not as correct as it might be,
and that it points in the wrong direction. XP as a process covers the
entire range of software development from glimmer in eye to CD on
every desk in the world. There are no phases in XP. That doesn't mean
it is one of RUP's phases: it is any and all of them. The restatement
points away from that truth. I shall return to that in a subsequent
reply, but for now I want to stick with Transition.

Small releases means real users where possible and all the XP
spokesmodels I know express it that way. And that job is the job of
the team, not solely of the customer.

The customer makes many stories that are not development stories.
Documentation stories, installation stories, quite often even kinds of
analysis or technology exploration stories. Teams with large numbers
of folks on the customer side often write customer stories and sign up
for those, just like programmers signing up for their stories.

It has always been this way. C3 put the entire system into production
every month after the first shipment. What we didn't do, to our
detriment, was turn on payment of part of the non-monthly population
when we were ready for them. But we should have.

Continuous Integration plus Small Releases can make every phase the
same. And the phase that Beck has challenged us to make it be is:
Transition.

Ron Jeffries
www.XProgramming.com
Analysis kills spontaneity.
The grain once ground into flour germinates no more. -- Henri Amiel


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dhemeryy
2002-08-28 15:31:05 UTC
Permalink
Hi Ron,
Post by Ron Jeffries
It is of course the case that whoever is providing "requirements" to
the team may be providing bad requirements. Even the RUP cannot
prevent this from happening.
Does RUP express ideas about how to reduce the likelihood of bad
requirements? That would be good enough for me. I don't need
prevention, just improvement.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Ron Jeffries
2002-08-28 12:23:13 UTC
Permalink
Post by Ron Jeffries
Post by Brad Appleton
We have
already agreed on this in previous threads, so I don't know what the problem
is with my restatement. All I have added is the statement that it is the
Customer's job to transition the working release to the user's environment
(of course, he could make stories about it, but they wouldn't be development
stories...), and that is what corresponds to the UP's transition phase.
The problem is that the restatement is not as correct as it might be,
and that it points in the wrong direction. XP as a process covers the
entire range of software development from glimmer in eye to CD on
every desk in the world. There are no phases in XP. That doesn't mean
it is one of RUP's phases: it is any and all of them. The restatement
points away from that truth.
The RUP calls out phases and milestones. The phases are there to
illuminate the milestones.

The RUP offers the first "Lifecycle Milestone", at the end of
Inception, as "decide whether to proceed with the project or cancel
it".

XP is designed to make that decision every other Friday, because the
XP software is /always/ shippable.

The RUP offers the second milestone, at the end of Elaboration, as an
assessment of whether the architecture is stable. "The project may be
aborted or considerably re-thought if it fails to meet this
milestone."

XP creates a stable architecture, sufficient to the features then
created, and keeps the architecture stable from week zero through week
N.

The RUP offers the third milestone, at the end of Construction, as
"All functionality has been developed and all alpha testing (if any)
has been completed. In addition to the software, a user manual has
been developed, and there is a description of the current release."
This means "almost ready to ship", as far as I can tell.

XP says to be fully ready to ship every two weeks. Features are either
done, or not planned yet, with occasional failures where we don't get
something done this iteration that we planned to. The effect is that
in every iteration, you have what you expected, plus or minus about
one feature, at that date. The system "ratchets" better and better.
Every feature is tested, with both Programmer Unit Tests and Customer
Acceptance Tests, at that time. If there needs to be a description of
the current version, check my chapter on Reporting. For comments on
incremental manuals, see
http://www.xprogramming.com/xpmag/manualsInXp.htm , and search for
"rant" on XProgramming.

The RUP offers the fourth milestone, at the end of Transition, as "At
this point, you decide if the objectives were met, and if you should
start another development cycle."

Guess what: that's what you did at the beginning of this iteration. XP
is all the RUP phases, in every iteration. That's the meaning of that
phase diagram that Beck draws.

By focus on milestones, the RUP creates phases. XP focuses on
ready-to-ship software and does not have phases. XP is for all phases,
not just one. Every XP phase includes little bitty copies of RUP's
great big phases.

But one does not contain the other. XP does not contain RUP and RUP
does not contain XP. They are fundamentally different
characterizations of software development, with lots of overlap in
ideas and -- I hope -- values.

Ron Jeffries
www.XProgramming.com
Fear is the mindkiller. --Bene Gesserit Litany Against Fear


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Pierre Boudreau
2002-08-28 13:49:06 UTC
Permalink
Post by Ron Jeffries
The RUP offers the second milestone, at the end of Elaboration, as an
assessment of whether the architecture is stable. "The project may be
aborted or considerably re-thought if it fails to meet this
milestone."
XP creates a stable architecture, sufficient to the features then
created, and keeps the architecture stable from week zero through week
N.
The RUP offers the third milestone, at the end of Construction, as
"All functionality has been developed and all alpha testing (if any)
has been completed. In addition to the software, a user manual has
been developed, and there is a description of the current release."
This means "almost ready to ship", as far as I can tell.
I am looking at the RUP right now and its definition of a release is to go
throuh everything from business modeling to deployment and produce a working
executable. This executable can be deployed internally or externally (to
the customer). Each phase (elaboration, construction, ...) can (and should)
contain multiple releases. I don't see any difference between RUP's
releases and XP's releases.

The difference between the releases in construction and the releases in
transition is that the transition releases will have help files,
documentation, help desk support, ... Unless the customer wants to have the
help file and user documentation stories in the first iterations (which
would surprise me a lot), this is still the same as XP's releases. If the
customer can not ship without user documentation, well, ... he can not ship
without user documentation and chances are that he will not ship after a few
iterations even if the rest is ready to ship every iteration.

I dont know if the RUP was always like this. Mr. Booch sais that it has
changed over time...


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Pierre Boudreau
2002-08-28 14:13:35 UTC
Permalink
Post by Pierre Boudreau
I am looking at the RUP right now and its definition of a release is to go
throuh everything from business modeling to deployment and produce a working
executable. This executable can be deployed internally or externally (to
the customer). Each phase (elaboration, construction, ...) can (and should)
contain multiple releases. I don't see any difference between RUP's
releases and XP's releases.
Just a clirification. I am refering to the definition of an iteration here.
Each iteration results in a release.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dan Rawsthorne
2002-08-28 17:23:59 UTC
Permalink
Ron, very well said, and I almost agree with it. In those cases where you
have the luxury of constantly deploying your system to the actual, final,
destination, I agree wholeheartedly with you.

However, XP is stronger than that. As I read it, XP is about providing
working software that satisfies a customer. That's it. The project's goals
are defined by the customer.

The UP is much more restrictive, and says that a cycle results in "a body of
source code embodies in components that can be compiled and executed, plus
manuals and associated deliverables." Kruchten says that the "purpose of
transition is to transition toeh software product to the user community"

In other words, the goals of a RUP cycle are defined by RUP, not the
Customer. This makes XP much more powerful as a process, IMHO... Dan ;-)
Post by Dan Rawsthorne
Post by Ron Jeffries
Post by Brad Appleton
We have
already agreed on this in previous threads, so I don't
know what the problem
Post by Ron Jeffries
Post by Brad Appleton
is with my restatement. All I have added is the statement
that it is the
Post by Ron Jeffries
Post by Brad Appleton
Customer's job to transition the working release to the
user's environment
Post by Ron Jeffries
Post by Brad Appleton
(of course, he could make stories about it, but they
wouldn't be development
Post by Ron Jeffries
Post by Brad Appleton
stories...), and that is what corresponds to the UP's
transition phase.
Post by Ron Jeffries
The problem is that the restatement is not as correct as it
might be,
Post by Ron Jeffries
and that it points in the wrong direction. XP as a process
covers the
Post by Ron Jeffries
entire range of software development from glimmer in eye to CD on
every desk in the world. There are no phases in XP. That
doesn't mean
Post by Ron Jeffries
it is one of RUP's phases: it is any and all of them. The
restatement
Post by Ron Jeffries
points away from that truth.
The RUP calls out phases and milestones. The phases are there to
illuminate the milestones.
The RUP offers the first "Lifecycle Milestone", at the end of
Inception, as "decide whether to proceed with the project or cancel
it".
XP is designed to make that decision every other Friday, because the
XP software is /always/ shippable.
The RUP offers the second milestone, at the end of Elaboration, as an
assessment of whether the architecture is stable. "The project may be
aborted or considerably re-thought if it fails to meet this
milestone."
XP creates a stable architecture, sufficient to the features then
created, and keeps the architecture stable from week zero through week
N.
The RUP offers the third milestone, at the end of Construction, as
"All functionality has been developed and all alpha testing (if any)
has been completed. In addition to the software, a user manual has
been developed, and there is a description of the current release."
This means "almost ready to ship", as far as I can tell.
XP says to be fully ready to ship every two weeks. Features are either
done, or not planned yet, with occasional failures where we don't get
something done this iteration that we planned to. The effect is that
in every iteration, you have what you expected, plus or minus about
one feature, at that date. The system "ratchets" better and better.
Every feature is tested, with both Programmer Unit Tests and Customer
Acceptance Tests, at that time. If there needs to be a description of
the current version, check my chapter on Reporting. For comments on
incremental manuals, see
http://www.xprogramming.com/xpmag/manualsInXp.htm , and search for
"rant" on XProgramming.
The RUP offers the fourth milestone, at the end of Transition, as "At
this point, you decide if the objectives were met, and if you should
start another development cycle."
Guess what: that's what you did at the beginning of this iteration. XP
is all the RUP phases, in every iteration. That's the meaning of that
phase diagram that Beck draws.
By focus on milestones, the RUP creates phases. XP focuses on
ready-to-ship software and does not have phases. XP is for all phases,
not just one. Every XP phase includes little bitty copies of RUP's
great big phases.
But one does not contain the other. XP does not contain RUP and RUP
does not contain XP. They are fundamentally different
characterizations of software development, with lots of overlap in
ideas and -- I hope -- values.
Ron Jeffries
www.XProgramming.com
Fear is the mindkiller. --Bene Gesserit Litany Against Fear
ad-free courtesy of objectmentor.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Phil Lewis
2002-08-28 12:25:14 UTC
Permalink
Post by jhrothjr
Post by Georg Tuparev
Post by jhrothjr
Once I've decided on Java versus C++ for my server, or VB
versus Python
Post by Georg Tuparev
Post by jhrothjr
for my client, I'm going to have a very large cost to change.
Why do you think so?
Surely that's not the kind of change we are talking about in collapsing the
cost of change curve?

A million lines of COBOL is going to cost a lot to change to C++. Doing it
in stages only spreads the cost.

The cost of change curve, I thought, was more about changes to
functionality.


**************************************************************************************************
The views expressed in this E-mail are those of the author and not necessarily those of Knowledge Management Software.
If you are not the intended recipient or the person responsible for delivering to the intended recipient, please be advised that you have received this E-mail in error and that any use is strictly prohibited.

If you have received this E-mail in error, please notify us by forwarding this E-mail to the following address:

***@kmsoftware.com
**************************************************************************************************


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
jhrothjr
2002-08-28 14:39:28 UTC
Permalink
Post by Phil Lewis
Post by jhrothjr
Post by Georg Tuparev
Post by jhrothjr
Once I've decided on Java versus C++ for my server, or VB
versus Python
Post by Georg Tuparev
Post by jhrothjr
for my client, I'm going to have a very large cost to change.
Why do you think so?
Surely that's not the kind of change we are talking about in collapsing the
cost of change curve?
Of course it's not. We were talking about some kinds of up front architecture decisions still being very difficult to change.
Post by Phil Lewis
A million lines of COBOL is going to cost a lot to change to C++. Doing it
in stages only spreads the cost.
Which is a very good example, best done as part of a necessary global rewrite.
Post by Phil Lewis
The cost of change curve, I thought, was more about changes to
functionality.
It's more about how you can design and maintain an application so that the design doesn't degrade. Most people believe, with a great deal of justification, that the rising cost of change over time is due to the application design degrading as it's maintained.

That's a completely different issue than architectural lockin.

John Roth
Post by Phil Lewis
**************************************************************************************************
The views expressed in this E-mail are those of the author and not necessarily those of Knowledge Management Software.
If you are not the intended recipient or the person responsible for delivering to the intended recipient, please be advised that you have received this E-mail in error and that any use is strictly prohibited.
**************************************************************************************************
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
dhemeryy
2002-08-28 15:51:36 UTC
Permalink
Hi John,
Post by jhrothjr
Post by Phil Lewis
The cost of change curve, I thought, was more about changes to
functionality.
It's more about how you can design and maintain an application so
that the design doesn't degrade. Most people believe, with a great
deal of justification, that the rising cost of change over time is
due to the application design degrading as it's maintained.
That's one factor. Another is the rising number of people who are
affected by changes.

Dale



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Booch, Grady
2002-08-28 16:02:47 UTC
Permalink
Post by dhemeryy
That's one factor. Another is the rising number of people who are
affected by changes.
[egb> ] And the tolerance to change within that community of people; there's
a practical limit to the degree and frequency of change that people can
absorb.

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Dinwiddie, George
2002-08-28 17:31:36 UTC
Permalink
Post by Kay A. Pentecost
Think about *reading* about a wonderful dinner... then
actually having one.
http://www.amazon.com/exec/obidos/ASIN/0679731148/alberg30-20

I couldn't get through a chapter without a trip to the kitchen.

To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Loading...