Laurent Bossavit wrote:

> However... just *what* are the "tests we're always writing" you and
> your comrades were thinking about ? Maybe some of the specific ones

        We're thinking not exactly about a test case (eg: "check if your
salary > 0"), but some good test practices, like testing limits of an
array, or testing if a list is empty before iterating over it. Or maybe
testing if the parameters of a "setAttribute()" method aren't null, that
I think is something common in most of the applications.
        I think we were thinking about test rules, not test cases.

        Thanks for your opinion!

        Joaquim

> From: Joaquim Pedro C. de Oliveira
> Laurent Bossavit wrote:
>
> > However... just *what* are the "tests we're always writing" you and
> > your comrades were thinking about ? Maybe some of the specific ones
>
>        We're thinking not exactly about a test case (eg:
> "check if your
> salary > 0"), but some good test practices, like testing limits of an
> array,

Isn't that what the JVM does? Or, if you're talking C++, how about
overriding operator[]()?

> or testing if a list is empty before iterating over
> it.

Again - couldn't your list either gracefully handle that, or check on its
own?

> Or maybe
> testing if the parameters of a "setAttribute()" method aren't
> null,

What if you couldn't pass in a NULL?

> that
> I think is something common in most of the applications.
>        I think we were thinking about test rules, not test cases.

If a test is mandatory again and again, maybe you need to change your code?
Wouldn't it be easier if it never again would be a problem AND you don't
have to write the tests?

It's hard to judge without knowing your situation, but I guess the extreme
attitude would be to make the problems go away, not test for them
everywhere...

Bye,
   Robert

> > From: Dinwiddie, George [mailto:George.Dinwiddie@...]
>
> > Blum, Robert said:
> > > I still do believe that _pure_ research (or
> > > \'direction finding\',or ,  for lack of a better word,
> > > \'futzing\' ) can advance
> > > faster if you drop some of the XP practices.
> >
> > Robert,
> >
> > What practices do you drop in order to go faster?
>
>\"Blum, Robert\" <rblum@...>
> All of them ? <evil grin>
>
> OK, seriously -
>
> Pair programming goes. Planning Game. Customer Tests. Metaphor. I gave
> the
> reasons in a previous post, I think.
>
<snip />
> Sometimes there, sometimes not:
> Test First.
> Continuous integration.
> Sustainable Pace. I\'m with Alistair on that one - sometimes, a 36 hour
> stretch actually feels good. It seems to feel less good if you do it
> too
> often, though :)

For my part, the *only* way in which a 36-hour stretch feels good is as a
reminder that I don\'t have to do it very often any more. It\'s a reminder of
how
far I\'ve come as a programmer that I don\'t rely on it any more. The long
hours,
in and of themselves, are PURE EVIL. I love my wife and my cats more than my
job.

J. B. (Joe) Rainsberger
President, Diaspar Software Services
http://www.diasparsoftware.com
Let\'s write software that people understand.

At 02:42 PM 2/28/2002 -0600, you wrote:
>  The long hours,
>in and of themselves, are PURE EVIL. I love my wife and my cats more than my
>job.

AMEN!


David Olivier
Naval Research Laboratory
Digital Mapping, Charting & Geodesy Analysis Program
Code 7440.2

> From: tranzpupy [mailto:tranzpupy@...]

> As a recent newcomer to the list, I'll agree that's one of the
> things.
>
> I also watched how newcomers were treated.
>
> And, how individual disagreements were treated.
>
> My judgment (Sorry, Ron, if that's *your* job, <grin>) is that people
> are treated really well here, and pretty much get back what they send
> out.
>
> With a little added humor, for spice.

That has also been my observation.  If I go to the home team's field, and
ask question about how they play, they'll probably be glad to talk all day.
If I go there and demand explaination for why I shouldn't call their
strategies stupid, I'll probably get rebuffed.

As I should.

Joe


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

> For my part, the *only* way in which a 36-hour stretch feels
> good is as a
> reminder that I don\'t have to do it very often any more.
> It\'s a reminder of how
> far I\'ve come as a programmer that I don\'t rely on it any
> more.

I don't rely on them either. Do you _never_ enter a state of flow where you
can just go on? Do you never have the feeling that if you just add that one
more feature, it will be so much better?

Yes, the last one does not happen if you strictly follow XP. What if you
explore on your own?

> The long hours,
> in and of themselves, are PURE EVIL. I love my wife and my
> cats more than my
> job.

I love 'em both. (MY wife and MY cats, and MY job, that is :)

And sometimes, I just encounter a challenge that is too good to pass up
anyways. It doesn't happen often. But when it happens, it's a fun 36 hour
stretch. And no, just putting in time to get things done is not my idea of
fun either.

Bye,
   Robert

P.S.: What's with the escaping of all quotes?

Kyle Cordes wrote:
>
> From: "Peter Hansen" <peter@...>
>
> > > It will put you in a worse negotiating position when the money
> > > runs out, because they will probably take the 90% functionality
> > > (it was the most important 90%) and go home.
>
> > That still doesn't hurt you, because after this successful project,
> > the customer will come rushing back to _you_, and no one else, when
> > they go to subcontract the next project.  In fact, they'll start
>
> The funny thing, is that sometimes when projects go somewhere similar to
> the fictional scenario I listed, they are nonetheless declared a success
> and development keeps going.

Too true.

> If you were paying someone to build you a new kitchen, and they went
> 100% over budget, would you hire them for the next kitchen?  I wouldn't,
> but it appears to happen regularly in software development.

Well, *I* wouldn't hire them again either, but I agree it happens.

On the other hand, I wouldn't care to be on the receiving end of this
attitude either.  I'd much prefer actually finishing the project, even
if just to 90%, and them come back to take on a *new* challenge with
a different context.  More interesting that way.  And I'd feel better
about myself than I did when I was consulting and billing by the
hour and my customer's project went 300% over schedule.  They were,
admittedly, always reasonably happy, but I was unhappy for them. :)

-Peter

Bill Tozier wrote:
>
> On or about 2/27/02, Peter Hansen wrote something like:
>
> >I think XP is highly suited for use in areas where the
> >customer is doing exploratory work, whether pure research or applied,
> >since it focuses so well on delivering results quickly to allow
> >feedback to prevent getting too far off track.
>
> [Swinging my attempt at a thread elsewhere around to bear on this one]
> Certain others have said, pointedly and succinctly, that the
> developer should not be the customer in proper XP. Are you suggesting
> that the current research programming culture, which stresses
> cowboyish do-it-yourself style, could be moved to include PP,
> test-first, and all the rest?

Largely, yes.  I don't entirely agree with the idea that the
customer cannot be one of the developers, at least in a software
research project.  On the other hand, it also looks to me like
it works fine if the customer, even though with the ability to
be a developer, just acts as customer and defines the directions
to be taken and judges the results.

> If I promise to agree with your story, "Researchers will agree to try
> XP," will you tell me how to implement it?

Sure, but my instructions won't be any more helpful than +tim's
probably were to you.  I believe you can just approach it as
you would any XP project.  Not seeing how that approach would
not work, I'm unable to give you better guidance.

(We've used the technique at least once here, with two people
doing a speculative development last summer with me as customer,
attempting to advance the state of the art along one of the
bleeding edges of web technology.  The results took longer than
I'd hoped, but as customer I was eventually satisfied both
with the rate of progress and the eventual results.  I didn't
notice anything significantly different in the research project
than I have in subsequent development projects, AFAICT.)

-Peter

Hi Dossy,

> I guess the reformed con of XP is:
>
> It requires every member of the project to share a common goal of
> delivering high quality software in a timely fashion.  It also
> requires every member of the project to positively and
> enthusiastically support and utilize XP practices.

This doesn't fit with some of the stories I've heard about how people
are using XP.

For example, Extreme Programming in Practice, and stories from other
people, tell about projects that succeeded even though the team's use
of the practices was inconsistent.

I've read any number of stories here from people who were highly
skeptical, tried some practices anyway (less than enthusiastically),
and were won over by how well the practices worked.

From these stories, I get the impression that XP sometimes succeeds
even with somewhat-less-than-enthusiastic support and use of the
practices.

Dale

Hi, im doing a project on creating a automated refactoring tool, and ive created
a simple survey which is multiple choice and only a few questions, if any of you
could pass on by and give it a fill in id be greatly appreciative.

Ill post the results of the survey to the group when its done in about a month
if any ones interested.

Cheers and thanks for your help

Andrew

To vote :   http://test.on30.co.uk/survey/index.php

To view the results so far : http://test.on30.co.uk/survey/results.php

and thanks again


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

--- In extremeprogramming@y..., "Charlie Poole" <cpoole@p...> wrote:

> A good manager over an XP team would
> be clearing obstacles rather trying to control how things are done.
>
> Of course, the hard thing is to convince a manager to act that way.

I've always been told that this is how all good manager's act,
regardless what sort of team they manage.

Erik Meade
http://junit.org
emeade@...

-----------

Views expressed in this message represent those of Object Mentor.

On 2002.02.27, Ron Jeffries <ronjeffries@...> wrote:
> > Dossy was (it seems to me) making a point about what people say
> > in public and what they practice in private. And it seems to me that
> > you are making the same point. Do you agree with Dossy or
> > disagree ? Or am I misunderstanding one, or both, of you ?
>
> Dossy said that you have to want to be successful to do XP. It seemd
> he was saying that (a) there are people who don't want to be
> successful and (b) people who don't want to do XP don't want to be
> successful.
>
> I disagree with both of those.

A person who is on a diet may tell you they are hungry but
refuse to eat.  Do they want to eat?  Are they really hungry?

A person who is developing software may tell you they want to
ship quality software on time but they refuse to take the
steps (we as XP practitioners) believe are necessary to do
just that.  Do they really want to deliver quality software
on time?  Are they just saying it and believing it but
not acting in such a way to achieve their desire?

I don't think I ever said anything that translates to (b), but
it's entirely possible.  Either way, I certainly didn't mean
(b).

> XP was not designed, as I understand it, with a focus on "how to
> produce quality software". In fact, one way of lookking at it is that
> XP has production of quality software as a /prerequisite/.
>
> XP produces quality software, not because it wants to, but because it
> /has to/.
>
> Does that compute?

Not really.  Sounds like you're selling snake oil, there.

I think the only prerequisite for XP is complete cooperation across
the entire team involved in the project, from top (management) to
bottom (developers).  Given this prerequisite and a thoughtful process
geared towards the aligned goals of the whole team, the goals will
be achieved.

Therefore, make your goals to deliver quality software that
delivers value to the business on time ... and, well, you'll
get just that.

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

On 2002.02.28, Laurent Bossavit <laurent@...> wrote:
> > I believe that the big issue against XP is /not/ that some people
> > don't want the kind of success that we offer. I believe that it is
> > people who /do/ want the kind of success that we offer, and through
> > honest ignorance or honest disagreement, do not believe that our
> > process is the best way to get that success.
>
> Ah, perfect summation.

I agree.  Ron hit it right on the head.

> I want to agree with you, Ron. But I've known people (my boss for
> instance) to say, and do, things for which the most charitable, the
> most plausible interpretation *I* could find was that they did not want
> the kind of success we offer.

That's exactly what I'm talking about.  I can believe that the
person (like your boss) genuinely wants to succeed.  They even
explicitly express it verbally.  However, their actions and
other externally measurable output indicate otherwise.  A person
in conflict, so on and so on.

> But maybe "want" is the word at issue. I've been a smoker for many
> years. I always knew it was a serious health problem, so under one
> meaning of the term I've always "wanted" to quit. Nevertheless,
> though I didn't "want" to I was smoking a pack a day or so.
>
> I could *claim* I value my health and a long life, but my actions belie
> that claim. My de facto objective, as my friends and family (or the
> non-smokers among them) observe with some puzzlement, appears
> to be a reduction of my life span.
>
> Honest ignorance or honest disagreement can *not* enter into this,
> since I know and agree that smoking is bad for my health.
>
[...]
>
> I honestly don't know how to explain that someone will split a team
> in 2, agreeing that it reduces the team's effectiveness, and justify
> the decision by saying "it's a management decision"... other than by
> assuming that their de facto objective isn't success as XP defines it.

Right on.

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

On 2002.03.01, dhemeryy <dale@...> wrote:
> Hi Dossy,
>
> > I guess the reformed con of XP is:
> >
> > It requires every member of the project to share a common goal of
> > delivering high quality software in a timely fashion.  It also
> > requires every member of the project to positively and
> > enthusiastically support and utilize XP practices.
>
> This doesn't fit with some of the stories I've heard about how people
> are using XP.
>
> For example, Extreme Programming in Practice, and stories from other
> people, tell about projects that succeeded even though the team's use
> of the practices was inconsistent.

Some practices may not be necessary (or as necessary) for a
specific instantiation of XP (where XP is instantiated on a
per-project basis).

For those projects that succeeded while not fully utilizing the
XP practices, I say that those teams lucked out in that the
practices they didn't fully use (or use consistently, etc.)
were not necessary (or as necessary) for the success of their
specific project.

Since I haven't been on so many countless projects to be able
to recognize from past experience exactly what projects require
which XP practices, I naively hedge my bets and suggest that
all of them be fully utilized to minimize risk of failure.

Maybe as I get wiser and more experience, I can safely decide
per-project which aspects of XP are optional for a specific
project.  Until then, I'll leave the knobs turned up to 11.
I'd rather come out of a successful project saying in
retrospect, "Gee, we didn't really need to do X, Y and Z
after all," rather than after a failed project saying,
"Boy, I really wish we'd done X, Y and Z."

> I've read any number of stories here from people who were highly
> skeptical, tried some practices anyway (less than enthusiastically),
> and were won over by how well the practices worked.

Imagine what it would do to their projects if they'd done all of
the practices fully?  Wow.  What would that do to the odds of
the team not delivering quality software on time?  Wow.  Is
there any compelling reason not to do just that?  (Other than
the fickle human touchy-feely reasons?)

> >From these stories, I get the impression that XP sometimes succeeds
> even with somewhat-less-than-enthusiastic support and use of the
> practices.

Sometimes.  Willing to take the risk?

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

Around Thursday, February 28, 2002, 9:40:40 PM, Dossy wrote:

>> XP was not designed, as I understand it, with a focus on "how to
>> produce quality software". In fact, one way of lookking at it is that
>> XP has production of quality software as a /prerequisite/.
>>
>> XP produces quality software, not because it wants to, but because it
>> /has to/.
>>
>> Does that compute?

> Not really.  Sounds like you're selling snake oil, there.

Well, think about this:

1. If you don't have your tests and keep them running, you can't
refactor safely. If you can't refactor safely, you can't evolve. If
you can't evolve, you wedge.

2. If you don't keep the code simple, your velocity will decline
toward zero. You'll wedge.

Therefore both quality-as-bug-free and quality-as-good-code are
necessary to keeping XP going. If you don't produce quality code, XP
won't work.

Hmm?

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

Around Thursday, February 28, 2002, 9:46:52 PM, Dossy wrote:


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

Page 70 of what?

Ron Jeffries
www.XProgramming.com
You can observe a lot by watching. --Yogi Berra

On 2002.02.28, dhemeryy <dale@...> wrote:
> > While it's easier to muddle through another methodology and do it
> > half-assed and produce a half-assed output, XP is (IMO) more
> > hit-or-miss, which is probably why it's quite apropos to call it
> > "Extreme".
>
> Now I'm getting another interpretation of your earlier comment.  Let's
> see if I'm getting closer:  Compared to other methodologies, XP is
> more sensitive (less forgiving?) to your commitment to doing all of
> the practices and sticking with them.  Is that close to what you
> meant?

It's close.

If you don't do Iteration Planning, how will you have any idea
what you'll deliver by when?

If you don't do Acceptance Testing, how will the Customer know
that what the team is producing delivers value and is of high
quality?

If you don't Pair Program, what steps will you take instead to
ensure that code gets written well?

If you don't Design Test-First, how will you know that your
design is as simple as it can be but still delivers the
functionality that's required?

...

All (good?  worthwhile?) methodologies try to address all these
concerns.  Since Extreme Programming is so "lean" (I don't think
XP is Agile, personally) and "extreme", it really needs
practitioners to do all the practices and sitcking with them.
Some projects may not require all of them, or all of them done
to the max, but at the start of a project, how can you possibly
know which ones aren't as necessary?

All the XP practices are the simplest (leanest?) way of achieving
each necessary piece of the software development process, and
in such a manner, support each other making each practice even
that more useful than the practice by itself.  That's why I
say that substituting a different solution instead of doing the
XP practice will be less effective.  Sometimes, less effective
is still effective enough for a particular project.  Even a
blind squirrel finds a nut, once in a while.  (Lucky.)

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

On 2002.02.27, alex@... <alex@...> wrote:
> One of our latest little debates involved exactly how often to
> refactor.

You should refactor as soon as and whenever it would make
completing your current task go faster and/or become easier
if you refactor.

This can be before you start writing tests, as you're writing
tests, after you've written tests, as you're writing code
to make a test pass, or after your test passes.

It can be on test code, or code under test.

That's why it's called "Refactor Mercilessly" -- take no prisoners.
No code is sacred, ever.

> The debate on that last one seemed to be between those who think that
> once a test passes, you're done, and you should move on; and those who
> say that merciless refactoring after the tests pass makes the code
> more agile -- my metaphor was of coiling a spring, ready to sproing in
> whatever new direction arises for the next task -- and that you
> shouldn't count a task as done until the tests pass *and* you've
> finished all obvious refactorings.

A task is done when its tests pass.  Your (the programmer's) work is
done when all the tests pass and the code is as simple and flexible
as it can be.

Some days, you have to go home even when your work isn't done.
That's just a fact of life.

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

Ron Jeffries wrote:
>
> Around Thursday, February 28, 2002, 9:46:52 PM, Dossy wrote:
>
> >   "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)
>
> Page 70 of what?

I'm ever more convinced that Google is god:

http://www.google.ca/search?q=realized+fastest+change+laugh+folly

leads one rapidly to:

2. Spencer Johnson, M.D. (1998) Who Moved My Cheese?, pp70, 72. New York,
NY: G.P. Putnam's Sons.

Freaky, really. :-)

-Peter

On 2002.02.28, Phlip <pplumlee@...> wrote:
> aviggio sez:
>
> > Thanks for the responses, Kent and crew. The Zoo Game went over well,
> > and of course the first thing said after the timer ran out was "what
> > was the purpose?"... I sampled some of the responses and they got the
> > point -- I think ;)
> >
> > I'll certainly use it again. The weather was pretty nasty so we only
> > have about twenty audience members. Our next two meetings will
> > probably be closer to 60-70 so it should be even louder!
>
> Instead of zoos, tell them to talk about politics, religion and/or sex.

Then, record the audio and then apply a clamping algorithm to the
recorded sound and you'll end up with the complete works of William
Shakspeare read aloud.

Then, play that in reverse, and you'll get the Necronomicon read
aloud in Latin.

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

--- Peter Hansen <peter@e...> wrote:
> [...]
> So what was the problem again? :-)
> -Peter

Good question!

The original problem was this:
XP doesn't tell you how to estimate and bid on a fixed-bid contract.
You have to use some other estimation and bidding technique if you
wish to compete in that marketplace.


Which is not to say that XP shouldn't be used to implement the system
once you get the contract.  Only that XP doesn't help you get the
contract.

Most XP discussion seems to be of the concept "you shouldn't do
business that way."  Nice idea, I say, but I have a mortgage to pay,
and maybe a cat to feed.  ;->
   -- jeff

On 2002.02.28, Ron Jeffries <ronjeffries@...> wrote:
> Around Thursday, February 28, 2002, 9:46:52 PM, Dossy wrote:
>
> >   "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)
>
> Page 70 of what?

_Who Moved My Cheese_

http://www.amazon.com/exec/obidos/ASIN/0399144463/panoptic0f

Don't you remember that long ugly thread I started months ago
about this book?  :-)

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

--- In extremeprogramming@y..., "geektank" wrote:
> --- In extremeprogramming@y..., "Charlie Poole" wrote:
>
> > A good manager over an XP team would be clearing
> > obstacles rather trying to control how things are done.
> >
> > Of course, the hard thing is to convince a manager to act
> > that way.
>
> I've always been told that this is how all good manager's act,
> regardless what sort of team they manage.

Yes, good managers act this way. These are managers who work for
their staff. The other kind of manager thinks his staff works for
him. This type of manager thinks the other type is weak. They don't
think good managers should act this way and don't think their own
sytle is bad. If you have one of these managers, you can't convince
them to act differently.

-- Mike
Eugene, OR

Hi Dossy,

> > I've read any number of stories here from people who were highly
> > skeptical, tried some practices anyway (less than
> > enthusiastically), and were won over by how well the practices
> > worked.
>
> Imagine what it would do to their projects if they'd done all of
> the practices fully?  Wow.  What would that do to the odds of
> the team not delivering quality software on time?  Wow.

Exactly.  I suspect that any methodology that works shares this
feature with XP.  If you're less faithful to the advice in the
methodology, you get fewer of the benefits.  If you're more faithful,
you get more.

What I'm still not understanding is: what makes this a con for XP?  I
don't see how XP is any different from any other methodology in this
respect.

> Is there any compelling reason not to do just that?  (Other than
> the fickle human touchy-feely reasons?)

All reasons are fickle human touchy-feely reasons.

Dale

On 2002.02.28, Ron Jeffries <ronjeffries@...> wrote:
> >> XP produces quality software, not because it wants to, but because it
> >> /has to/.
[...]
>
> 1. If you don't have your tests and keep them running, you can't
> refactor safely. If you can't refactor safely, you can't evolve. If
> you can't evolve, you wedge.
>
> 2. If you don't keep the code simple, your velocity will decline
> toward zero. You'll wedge.
>
> Therefore both quality-as-bug-free and quality-as-good-code are
> necessary to keeping XP going. If you don't produce quality code, XP
> won't work.

Nice, nice.  Great explanation.

> I'm giving the best advice I have. You get to decide whether it's true
> for you.

Couple that with "free advice is worth just that" and it becomes
_really_ interesting ...

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
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)

Hi Dossy,

> All the XP practices are the simplest (leanest?) way of achieving
> each necessary piece of the software development process, and
> in such a manner, support each other making each practice even
> that more useful than the practice by itself.  That's why I
> say that substituting a different solution instead of doing the
> XP practice will be less effective.

Okay.  I think I understand your statement.  Now I think I'm starting
to understand the cause-and-effect behind your statement.

Here's my interpretation:  XP has only essential practices.  Other
methodologies include helpful-but-nonessential practices that you
might be able to remove safely.  But if you remove a practice from XP,
you're removing something that is (very likely to be) essential to
your success.

Am I getting the cause-and-effect right?

Dale

Hi Laurent,

> > No, they're different.  I trust the pain in my thumb more than I
> > trust information that I have to interpret through some mental
> > model.
>
> You think you're not interpreting the pain in your thumb through
> some mental model ?

Doh!

Dale

Ron Jeffries wrote:

> Well, think about this:
>
> 1. If you don't have your tests and keep them running, you can't
> refactor safely. If you can't refactor safely, you can't evolve. If
> you can't evolve, you wedge.
>
> 2. If you don't keep the code simple, your velocity will decline
> toward zero. You'll wedge.
>
> Therefore both quality-as-bug-free and quality-as-good-code are
> necessary to keeping XP going. If you don't produce quality code, XP
> won't work.
>
> Hmm?
>

If only the wedging were immediate, it might be an easier sell.  As it is, the
wedging
is a slowly tightening noose.  When it becomes uncomfortable, it's often times
too
late.

Mike

--
Mike Clark
Clarkware Consulting, Inc.
http://www.clarkware.com
720.851.2014

jeffgrigg63132 wrote:
>
> The original problem was this:
> XP doesn't tell you how to estimate and bid on a fixed-bid contract.
> You have to use some other estimation and bidding technique if you
> wish to compete in that marketplace.
>
> Which is not to say that XP shouldn't be used to implement the system
> once you get the contract.  Only that XP doesn't help you get the
> contract.

Okay, how about this then, which I think helps answer the first
question but doesn't necessarily help with the second.

With XP, if you have a history of successful projects, you have
an excellent idea of your velocity on several types of development
and strong evidence that your process is safe, repeatable,
sustainable, and generally very effective.

With this security blanket, you can examine a fixed-bid contract
with higher confidence than you could with previous processes.
You take a much longer time examining the project requirements
up-front than you would have to with standard XP.  The technical
leads/principals/whoever would usually look at such an RFQ
familiarize themselves with it to the point where they feel
confident they have a pretty good understanding of what it
involves.

Then they sit down with the team, work out the various stories
involved, and estimate them.  Taking maybe a little longer
than one normally would in the PlanningGame.  A release plan
is prepared.

The business side examines the risks involved, takes into
account the team's level of confidence, adds a suitable
safety margin, and submits a proposal.  Everyone goes to
the Go-Cart place for the rest of the afternoon.

The customer examines the bids, and does one of two things.

They pick another company, which underestimated the work required
and which doesn't use XP and which is very likely to kill
themselves trying to make the aggressive target date at a fixed
price, and in the end everyone ends up fairly unhappy, burned out,
and not as rich as they hoped.

Or they pick the XP company, which nominates a local expert on
the contract to be the Customer and the team proceeds to develop
the product.  Tradeoffs are made, scope is cut when needed, and
the company delivers fairly close to the time predicted since,
after all, they are using XP.  Maybe 90% is available when the
end of the release plan is reached, which is okay because the
business guys added 17% risk contingency (in addition to 35%
margin for profit) and since they eventually exceed the target
by only 11% the gross margin is actually more like 38% and
everyone goes home with bonuses.

Or words to that effect.

In summary, if XP really delivers on the promise of
repeatability, predictability, sustainability, etc.,
why wouldn't it be the _best_ approach to a fixed-
price contract, and why wouldn't it be the best way to make
estimates and prepare your bid?

As far as your comment about it maybe being suitable for use
on the contract, but doesn't help you get the contract, I
guess other than having a proven track record of success
using it, you may be out of luck if a customer is simply
unable to fathom how you could provide a solution for them
if you aren't using RUP...

-Peter

Let me chime in on this issue. I don't think it has anything to do with wanting
to succeed or not. I think that it has to do with discipline. People want to
succeed, and may even know how to succeed, but do they have the discipline to do
it? XP requires that each member of the team develop the discipline to stick
with the practices.

IMHO, one of the reasons for high-ceremony processes is that they try to replace
individual discipline with process discipline, which is enforced by a QA group,
normally. This means that not everyone has to have the discipline to do it
right, just the process police...

So, agile processes are quicker, cheaper, and more responsive, but require more
disciplined people. High ceremony processes can get the job done with less
disciplined people, with a higher cost in both money and time.

As I said before, think Special Forces A-team versus regular infantry... this
analogy works for me - but I'm a soldier...

Dan  ;-)

Dossy <dossy@...> writes:

> On 2002.02.28, Laurent Bossavit <laurent@...> wrote:
> > > I believe that the big issue against XP is /not/ that some people
> > > don't want the kind of success that we offer. I believe that it is
> > > people who /do/ want the kind of success that we offer, and through
> > > honest ignorance or honest disagreement, do not believe that our
> > > process is the best way to get that success.
> >
> > Ah, perfect summation.
>
> I agree.  Ron hit it right on the head.
>
> > I want to agree with you, Ron. But I've known people (my boss for
> > instance) to say, and do, things for which the most charitable, the
> > most plausible interpretation *I* could find was that they did not want
> > the kind of success we offer.
>
> That's exactly what I'm talking about.  I can believe that the
> person (like your boss) genuinely wants to succeed.  They even
> explicitly express it verbally.  However, their actions and
> other externally measurable output indicate otherwise.  A person
> in conflict, so on and so on.
>
> > But maybe "want" is the word at issue. I've been a smoker for many
> > years. I always knew it was a serious health problem, so under one
> > meaning of the term I've always "wanted" to quit. Nevertheless,
> > though I didn't "want" to I was smoking a pack a day or so.
> >
> > I could *claim* I value my health and a long life, but my actions belie
> > that claim. My de facto objective, as my friends and family (or the
> > non-smokers among them) observe with some puzzlement, appears
> > to be a reduction of my life span.
> >
> > Honest ignorance or honest disagreement can *not* enter into this,
> > since I know and agree that smoking is bad for my health.
> >
> [...]
> >
> > I honestly don't know how to explain that someone will split a team
> > in 2, agreeing that it reduces the team's effectiveness, and justify
> > the decision by saying "it's a management decision"... other than by
> > assuming that their de facto objective isn't success as XP defines it.
>
> Right on.
>
> -- Dossy
>
> --
> Dossy Shiobara                       mail: dossy@...
> 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:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/