--- In extremeprogramming@yahoogroups.com, "Kay A. Pentecost"
<kayp@i...> wrote:
> Well, I don't know.  Do we count bugs by broken tests, or by
problems that
> actually get to "testing"?

What does the word 'bug' mean to you? It's not a trick question, it
does mean subtly different things to different people.

>
> Maybe I wasn't clear.  Suppose I make one fix, which supposedly
fixes the
> bug I was supposed to fix,
> and 10, or even 20 tests break.
>

This is entirely possible/probable. If you could change code and not
break multiple tests, it would be a bigger cause for concern.

>
> Now suppose that the bug I fixed was in step 1 of a three step
process.
> Nobody's been able to do or test step 2 because of the bug in step
1. Now
> they find a bug in step 2.  The original programmer claims that the
person
> who fixed the bug in step 1 created it.  While that's *possible*
it's not as
> likely as the fact that the first bug hid the second.
>
> When there's no existing tests, there's nothing to alert the bug-
fixer than
> something else has been broken.

Well, step 2 and 3 can't have been delivered, so it's not a bug the
customer will have visibility of.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

Btw, here's a quick summary from William Wake that might be useful:
http://www.xp123.com/xplor/xp0502/index.shtml

Best regards,
Norman

-----Original Message-----
From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Kent Beck
Sent: Sunday, July 31, 2005 1:41 PM
To: extremeprogramming@yahoogroups.com
Subject: [XP] XP Explained, 2nd edition

All,

While at Agile 2005 this week I answered several questions of the form, "How
much is different in the second edition?" For the benefit of all those who
have this question and haven't asked it, the answer is that the text is a
complete re-write. The only words I copied and pasted were from the Learning
to Drive chapter. Everything else was written from scratch from my
five-years-later perspective. The same technical content is there (towards
the end we went through the first edition paragraph-by-paragraph and made
sure all the same concepts were covered), but the tone and perspective are
more inclusive and inviting.

To all the people who complimented Cynthia or I on the book, thank you very
much. I would appreciate it if you would post comments on Amazon. Most of
the reviews there are from the first edition.

Take care,

Kent Beck
Three Rivers Institute

Thanks! I've also seen Kent's feedback on Time & Material basis, Kent's
Optional Scope Contract article, Cyrus Innovation slides, user stories built
for one iteration, and some others...

The problem is most companies prefer Fixed Scope Contract (Time, Cost and
Scope). For new clients, they insist us to put in our proposal (early in the
beginning, before the project started & even before they choose a vendor)
the total cost needed and the time needed to built a set of complete
features. Then, based on these proposals (from several vendors) the client
will pick one vendor that they think provides the most competitive cost &
time for the 'scope'. I've tried the Time & Material basis but no customers
buy the idea.

What would be your strategy for this?

Best regards,
Norman

-----Original Message-----
From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Brill Pappin
Sent: Monday, August 01, 2005 11:14 AM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] How to invoice clients in XP projects

In case this helps, I bill at the end of an iteration with net 30 terms.
The idea being that by the end of an iteration, I've dealt with
everything the client signed off on, and because I'm doing vertical
slices (of course) the client can see the results of the time I'm
billing for.

Works for me, and my clients couldn't be more delighted.

Biggest problem I had was that I couldn't sell some of them agile and
scrum... now I simply tell them "this is how it will work" and if they
don't like it, I don't take them on.

Being organized is a must though... if your not good at it, try a good
tool like XPlanner... not ideal for a billing contractor, but it does
the trick (you have to do a little translation to get the time sheets
into you invoice format).

- Brill

Sridhar,

Applying Slack and Pair Programming, I would be comfortable signing up for
~3 hours of tasks per day, assuming I didn't have lots of outside
responsibilities. This answer seems so obvious to me that I suspect I am
missing the real question. What would happen at your workplace if you
followed this advice?

Sincerely yours,

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> sherlocksridhar
> Sent: Friday, July 29, 2005 1:29 AM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Task Volunteering when using pair programming
>
> Hi all,
>
> I am not sure if this has been asked before (I searched the messages,
> honest!!!), but I could not find a relevant thread.
>
> When developers volunteer for tasks, how much hours of tasks should
> each developer volunteer per day? Assuming 8 hours of worktime, when
> pairing is used, each developer may volunteer for just 4-6 hours.
> (going by the traditional 1/3rd - 2/3rd rule). However, if 6
> hours are
> taken up, how can he get another developer for the 6 hours, because
> that guy/girl will also need to complete 6 hours!!.
>
> Regards
> Sherlocksridhar
>
>
>
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

John,

I don't emphasize the divergence in agile development at Agile Alliance
events because it doesn't feel safe for me to say, "XP is different"in that
venue. I noticed that my open space sessions were the only ones that used
"XP" in the title at the Agile 2005 conference. I think there is substantial
disagreement between the different styles in values, principles, and
practices.

The Agile Alliance was formed to discover, articulate, and communicate the
common denominators between XP, Scrum, Crystal, FDD, ASD, and DSDM. It
doesn't surprise me that it hasn't resulted in open conflict. I think it
will be a sign of maturity of agile development when it is safe to say what
those differences are and when healthy conflict is seen positively.

Sincerely yours,

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> yahoogroups@...
> Sent: Friday, July 29, 2005 4:59 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Shifting of the Balance?
>
> People simply aren't reporting that degree of divergence,
> and, as far as I can tell, the originators of each of the various
> Agile methodologies don't believe that there is that much
> difference, either. They're certainly not reporting a wall, a
> snake, a rope, a tree and a fan.
>
> If they're pretending there's a lot of divergence, its for
> marketing reasons.
>
> For a second reason, I don't like comparing Agile to an
> elephant. I remember a Gif from a long time ago showing
> an elephant tap dancing - something having to do with
> making the IBM elephant move.

Manish,

The C3 project once went through all the defects found after code had been
checked in and discovered that all of them had been introduced by people
writing code alone. This isn't a quantitative metric, but it was a very
powerful qualitative metric.

Sincerely yours,

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of jainm76
> Sent: Tuesday, July 26, 2005 7:53 PM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Advise on measuring effectiveness of pair programming
>
> Hello! everybody,
>
> A litle of background: Till now i have been confined to working with
> iterative software development process. But now I am wanting to
> venture into the world of working with XP. That is the reason i joined
> this group to get insight into XP practices and their effective
> implementation.
> For the start i want to try out Pair Programming, Automatd testing,
> reviews, and continuous integration XP practices in my project.
> I want to know how do i measure the effectiveness of pair programming
> because practically no 2 tasks are comparable. what metrics
> should i use?
>
> regards
> manish

Phlip,

This sounds like the "XP is a recipe" metaphor to me. Since we are dealing
with people, who are quite good at being good in surprising ways, I don't
think the results will be predictable. An example is the furor caused three
years ago when (the names escape me but they are a British couple working in
Sweden) said they were getting just-fine results with functional testing and
without unit testing. People who were looking for a recipe gave them all
kinds of grief but they were quite satisfied with their development style.

I predict that you could point to a practice, speculate on the results of
leaving that practice "out" (since the practices are very flexible it
doesn't make sense to me to even say that), and be contradicted by actual
experience by someone on this mailing list.

Sincerely yours,

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Phlip
> Sent: Wednesday, July 27, 2005 7:19 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Article on XP pathologies?
>
> Paul Butcher wrote:
>
> > I am looking for an article which describes "XP Pathologies".
> > Specifically, I'm looking for a list of ways to tell that your local
> > implementation of XP is broken and needs remedial action.
>
> That's a totally good idea for an article. When you think you are
> doing XP, but leave out Practice X, and do all the others eXtremely,
> here's the symptoms you will get.
>
> Repeat for each practice.

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of John Carter
> Sent: Sunday, July 31, 2005 6:43 PM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Ob-literate programming
>
> > It was easier to continue refining the code than it was to
> try to explain
> > why it wasn't clean.
>
> What are you saying? "Don't describe, clean?" Xor "Describe
> to find what
> you need to clean, clean, then carry on describing?"

Whenever I found myself trying to explain why a bit of code wasn't as clear
as it could be, I found it was less work to go clean up the code first then
explain it. Ward and I wrote our first literate program to describe how the
ScrollController worked. We thought the code was pretty clean until we
started describing it. By the time we were done we had touched almost all of
the original code.

> > I also became aware of just how much there was to
> > communicate when describing code.
>
> Were you simply describing the implementation, or writing the
> requirement
> spec, high level design, detailed design, use cases, program,
> reference
> manual and user guide etc. etc. in one document?

Following Knuth's lead, I try to point out what I find interesting about a
program. I try to write a coherent story, so a reader can follow the program
end-to-end. Sometimes what is interesting is the design, or a clever use of
the programming language, or a performance optimization, or the theory
behind the program. I haven't ever incorporated a reference manual or user
guide, though. Those seem to me to be directed at a different audience.

Sincerely yours,

Kent Beck
Three Rivers Institute

Chris,

The concept you are refering to below sounds like blame, not accountability.
Whether I accept someone else's blame partly depends on whether I've given a
whole-hearted effort to the task. If I have, I find it easier to see
attempts at blame as not saying something about me.

The OP was asked to provide coverage metrics for his code. I think if I was
comfortable with my testing efforts, I would just report my coverage. If my
manager told me 80% just wasn't good enough, that could be the start of a
valuable conversation.

Sincerely yours,

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Chris Hanson
> Sent: Wednesday, July 20, 2005 10:51 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Is "skip the test" ever an option in XP?
> (was: about no-arg constructor)
>
>
> On Jul 20, 2005, at 1:03 AM, Kent Beck wrote:
>
> > I asked that question because in my own experience if I try to
> > wiggle out of
> > reporting some metric, it is generally because I am not
> comfortable
> > with the
> > underlying factor the metric is trying to measure.
>
> Sometimes people aren't comfortable with things for external
> reasons.  We may have done our best, and be comfortable with the
> result, but may have a management culture that likes to beat people
> up over a metric-of-the-week.
>
> When you're dealing with a pathological organization,
> "accountability" is not used to build mutual trust or respect.  It's
> used to enforce a position in a hierarchy, or at the least as a way
> to try and browbeat more time or work out of developers.
>
> There are way, way too many pathological organizations out there.
>
>    -- Chris
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>
>
>

Phlip,

In whose theory?

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Phlip
> Sent: Wednesday, July 27, 2005 7:15 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Article on XP pathologies?
>
> In theory, you do each practice in The White Book or The Silver Book,
> and it's XP.

Kent,

> An example is the furor caused three years ago when (the names escape me
> but they are a British couple working in Sweden) said they were getting
> just-fine results with functional testing and without unit testing.

That would be Geoff and Emily Bache. Article here:
   http://www.carmen.se/research_development/articles/crtr0203.pdf

They have a Web site up about the tool, TextTest:
   http://texttest.carmen.se/

Cheers,

-[Laurent]-
It is tempting to suppose that everyone might fully realize
his powers and that some at least can become complete exemplars
of humanity.  But this is impossible.  It is a feature of human
sociability that we are by ourselves but parts of what we might
be.  We must look to others to attain the excellences that we
must leave aside, or lack altogether. -- John Rawls

On Monday, August 1, 2005, at 12:06:44 AM, yahoogroups@... wrote:

> When people are playing the blame game, then they are playing
> the blame game, and there isn't a lot you can do technically about
> it.

> The only strategy that I've found to work is to make the blamer
> discover that the blame game doesn't work on you. After a few
> go-arounds they usually learn  better.

Do you do that with a stick, or what? ;->

But seriously, sometimes it works on the boss. What then?

> Think of it as behavior modification - how do you want
> them to behave, taking the environment into account?

And then?

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

Hi Paul,

A quick google for {xp "process smells"} turned up the following:

Recognizing and Responding to “Bad Smells” in Extreme Programming
Amr Elssamadisy & Dr. Gregory Schalliol

"We have identified areas of trouble in the
entire life cycle, including analysis, design, development, and
testing. For each practice we identify, we discuss the solution we
implemented to correct it and, more importantly, examine the
early symptoms of those poor practices (“bad smells”) that project
managers, analysts, and developers need to look out for in order
to keep an XP project on its swifter track."

http://www.thoughtworks.com/us/library/Recognizing%20and%20Responding%20to%20Bad\
%20Smells%20in%20Extreme%20Programming.pdf

aka http://tinyurl.com/dha5l

	 Good luck, Ben

Paul Butcher wrote:
> Hi - I'm hoping that the group can offer me some help with the
> following:
>
> I am looking for an article which describes "XP Pathologies".
> Specifically, I'm looking for a list of ways to tell that your local
> implementation of XP is broken and needs remedial action.
>
> I've had a hunt through the various XP books and websites, but can't
> find quite what I'm after - I can't believe that it isn't out there
> though!
>
> Background:
>
> I've recently been contacted by an ex-colleague who knows that I
> have run an XP team in the past. Her organisation has recently moved
> to XP (or at least they *think* that they have). She has described a
> set of pathological behaviour to me which is frankly scary:
>
> - No well defined customer
> - Customer not involved because they "don't have time"
> - "Stories" defined at a technical level, rather than something
> which is meaningful to the customer
> - Developers scheduling stories rather than the customer
> - No planning at all beyond the current iteration
> - No agreed units for story estimates
> - No "coach" role
> - etc. etc. etc.
>
> Before they can even begin to address all of these issues, they need
> to accept that they have a problem. The best way to do this would be
> if there was a website or book that she could point to and
> say "look - it says in here that if you're not doing <foo>, then
> you're not doing XP", or better yet "look - it says in here that if
> you experience symptom <bar> then you need to take remedial action
> <baz>".
>
> I know that this kind of thing is distributed throughout the XP
> literature, but what I'm ideally looking for is a single collection
> of XP pathologies which they can look at (my guess is that they're
> hitting a large proportion of them!).
>
> Thanks in advance for your help,
>
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
>
>
>
>
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>
>

Ron asked:

> Where's that radar chart of Bill Wake's? They could fill that out.

http://xp123.com/xplor/xp0012b/index.shtml

Regards, Ilja

On 7/31/05, Kay A. Pentecost <kayp@...> wrote:
>
> Hi, Ian,

> The code may be robust, but if you change the behaviour of a key
> > component while fixing a bug, all bets are off.
>
> Granted. But if one changes the behavior of a key component doesn't it
> usually become obvious when you run the system to make sure that hasn't
> happened before checking in the code?
>
> >
> > That's often the case where someone doesn't fully understand how the
> > code works and it's best prevented by adding tests, which
> > express your
> > understanding of the code, before changing it.
>
> Yes, makes sense. The problem happens when the tests express the bug
> fixer's understanding of the code, but not the original coders
> understanding
> of the code, doesn't it?
>
> Kay



I have always seen debugging as an iterative process. You fix a bug and
potentially find a bug/s. With TDD, (something I am just now getting my head
around) I would imagine that there are still times when you need to invoke
the debugger and walk through the code. However, I would image that this
happens quite a bit later in the process than in a code-fix environement, as
you have the tests to back you up.

So, you fix a bug an break 20 tests... at least you know that they are
broke, instead of having to run the code through any number of machinations
to "test" it. Is this how you have seen TDD work?

--
Matt Secoske
http://www.secosoft.net


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

Kent Beck wrote:

>Following Knuth's lead, I try to point out what I find interesting about a
>program. I try to write a coherent story, so a reader can follow the program
>end-to-end. Sometimes what is interesting is the design, or a clever use of
>the programming language, or a performance optimization, or the theory
>behind the program. I haven't ever incorporated a reference manual or user
>guide, though. Those seem to me to be directed at a different audience.
>
>Sincerely yours,
>
>Kent Beck
>Three Rivers Institute
>
>
Kent,

Have you published or posted any examples of  your literate programming?

Bill Rutiser
Gaithersburg, MD, US

Around Monday, August 1, 2005, 4:28:00 AM, Kent Beck wrote:

> I don't emphasize the divergence in agile development at Agile Alliance
> events because it doesn't feel safe for me to say, "XP is different"in that
> venue. I noticed that my open space sessions were the only ones that used
> "XP" in the title at the Agile 2005 conference. I think there is substantial
> disagreement between the different styles in values, principles, and
> practices.

> The Agile Alliance was formed to discover, articulate, and communicate the
> common denominators between XP, Scrum, Crystal, FDD, ASD, and DSDM. It
> doesn't surprise me that it hasn't resulted in open conflict. I think it
> will be a sign of maturity of agile development when it is safe to say what
> those differences are and when healthy conflict is seen positively.

Kent,

As you probably know, it's my current view that, while the
description of XP is more full and rich than the others, all the
so-called "Agile" methods are describing the same "platonic ideal"
object. (I say "current" because it may not always have been my
view, and may not be in the future.)

I certainly see differences in styles, and in various specifics.
Yet, unless we are willing to say things like "it's not XP unless
you pair program," it seems that XP needs to encompass, all on its
own, a wide range of practices, and to be sensitive to the values of
team members. As far as I've seen, there is no definitive answer to
whether a given team is or is not "doing XP". So ... is there some
allowable variability outside which one isn't?

If you would find this a safe place to discuss the ways that XP is
different, and the related IS / IS NOT questions, I'd be very
interested in the discussion, and I'd bet that many others would be
as well.

Regards,

Ron Jeffries
www.XProgramming.com
We cannot solve our problems with the same thinking we used when we created
them.
   -- Albert Einstein

Kent Beck wrote:

> This sounds like the "XP is a recipe" metaphor to me. Since we are dealing
> with people, who are quite good at being good in surprising ways, I don't
> think the results will be predictable. An example is the furor caused three
> years ago when (the names escape me but they are a British couple working in
> Sweden) said they were getting just-fine results with functional testing and
> without unit testing. People who were looking for a recipe gave them all
> kinds of grief but they were quite satisfied with their development style.

I seen that.

(Another factor was the lead programmer architected the system based
on his last three big gigs, so there was no design to emerge. The
existing design was very good.)

> I predict that you could point to a practice, speculate on the results of
> leaving that practice "out" (since the practices are very flexible it
> doesn't make sense to me to even say that), and be contradicted by actual
> experience by someone on this mailing list.

I meant the other way around. The pathologies and ways of failing
commonly indicate someone ignored evidence early on, and the evidence
might have indicated which practice was slacking off.

--
   Phlip
   http://www.c2.com/cgi/wiki?ZeekLand

From: "Kent Beck" <kentb.at.earthlink.net@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Monday, August 01, 2005 2:28 AM
Subject: RE: [XP] Shifting of the Balance?


> John,
>
> I don't emphasize the divergence in agile development at Agile Alliance
> events because it doesn't feel safe for me to say, "XP is different" in
> that
> venue. I noticed that my open space sessions were the only ones that used
> "XP" in the title at the Agile 2005 conference. I think there is
> substantial
> disagreement between the different styles in values, principles, and
> practices.

I both agree and disagree with this. My point was about project
management, not about either software construction or group process.
I will grant you that there are differences between XP and Scrum in
the project management area, but those differences are overwhelmed
by the similarities.

The real significant differences are that XP has a software construction
process, and none of the others do. XP has gone farther into the group
process than any of the others as well.

It is, I think, worth talking about those things. I've already mentioned
that I was rather disappointed by the "Agile Engineering Practices"
track on Sunday - the only one of the four talks that I would have
dignified as an engineering practice was the Fit one. The other three
were totally about project management.

One of the reasons I repackage XP into the three areas of
Agile Project Management, XP Colocated Small Group Process
and XP Software Construction is so that I can talk about it
without raising a lot of heat and relatively little light.

> The Agile Alliance was formed to discover, articulate, and communicate the
> common denominators between XP, Scrum, Crystal, FDD, ASD, and DSDM. It
> doesn't surprise me that it hasn't resulted in open conflict. I think it
> will be a sign of maturity of agile development when it is safe to say
> what
> those differences are and when healthy conflict is seen positively.

I see a merger happening, and I see XP's contribution as the
software construction process, possibly also the recognition that
small colocated teams are the most efficient way of constructing
software.

Sincerely,
John Roth

>
> Sincerely yours,
>
> Kent Beck
> Three Rivers Institute
>
>> -----Original Message-----
>> From: extremeprogramming@yahoogroups.com
>> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
>> yahoogroups@...
>> Sent: Friday, July 29, 2005 4:59 PM
>> To: extremeprogramming@yahoogroups.com
>> Subject: Re: [XP] Shifting of the Balance?
>>
>> People simply aren't reporting that degree of divergence,
>> and, as far as I can tell, the originators of each of the various
>> Agile methodologies don't believe that there is that much
>> difference, either. They're certainly not reporting a wall, a
>> snake, a rope, a tree and a fan.
>>
>> If they're pretending there's a lot of divergence, its for
>> marketing reasons.
>>
>> For a second reason, I don't like comparing Agile to an
>> elephant. I remember a Gif from a long time ago showing
>> an elephant tap dancing - something having to do with
>> making the IBM elephant move.
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Ron Jeffries wrote:

>On Sunday, July 31, 2005, at 6:56:12 PM, Joshua Kerievsky wrote:
>
>
>
>>Glad to hear that.  One minor suggestion -- we actually call them
>>"storytests" -- no space between story and test.   (The new FIT got it
>>right in some places and wrong in others.  Rick and Ward assure me
>>they'll fix it in later printings of their book).
>>
>>
>
>Hmm. "Storytests". A new word. I can think of some advantages to
>that, I guess ...
>
>
Ron -- I invented that word back in 2003 to communicate the connection
between tests and stories.  I'm surprised you haven't run across it
before -- "storytesting" is a practice in IXP, as is SDD, which stands
for storytest-driven development.

--
best regards,
jk

----
I n d u s t r i a l   L o g i c ,  I n c .
Joshua Kerievsky
Founder, Industrial XP Coach
http://industriallogic.com
http://industrialxp.org
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

Hi, Kent!

On Mon, 2005-08-01 at 01:28 -0700, Kent Beck wrote:
> This sounds like the "XP is a recipe" metaphor to me. Since we are dealing
> with people, who are quite good at being good in surprising ways, I don't
> think the results will be predictable. [...]
>
> I predict that you could point to a practice, speculate on the results of
> leaving that practice "out" (since the practices are very flexible it
> doesn't make sense to me to even say that), and be contradicted by actual
> experience by someone on this mailing list.

That's true, but I'm afraid I don't see the connection. Are you
suggesting that one shouldn't write articles of the "XP Pathologies"
form?

I ask because what you write is true about actual recipes as well, and
those still seem popular and useful for novice chefs.

William

--
William Pietri <william@...>

From: "Ron Jeffries"
<ronjeffries.at.XProgramming.com@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Monday, August 01, 2005 4:16 AM
Subject: Re: [XP] Creating new bugs when fixing old ones...


> On Monday, August 1, 2005, at 12:06:44 AM, yahoogroups@... wrote:
>
>> When people are playing the blame game, then they are playing
>> the blame game, and there isn't a lot you can do technically about
>> it.
>
>> The only strategy that I've found to work is to make the blamer
>> discover that the blame game doesn't work on you. After a few
>> go-arounds they usually learn  better.
>
> Do you do that with a stick, or what? ;->

Remember that Kay and I share a background in
NLP (Neuro-Linguistic Programming, not Natural
Language Programming.) We've got some tools
available in that area. Other people have other
tools that work as well. Frex, at the last Albequerque
Spin meeting we had Gerald Weinberg give a talk
that turned out to be about disfunctional interpersonal
and group patterns, and how to deal with them.
Quite interesting.

> But seriously, sometimes it works on the boss. What then?
>
>> Think of it as behavior modification - how do you want
>> them to behave, taking the environment into account?
>
> And then?

You  go on to the next problem, which hopefully will be
more interesting.

John Roth


>
> Ron Jeffries
> www.XProgramming.com
> Fear is the mindkiller. --Bene Gesserit Litany Against Fear
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>
>
>

On Sat, 2005-07-30 at 06:50 -0400, Ron Jeffries wrote:
>
> Where are these people? If I'm passing through, I could drop in on
> them.

That would be excellent. Likewise, if they're in the northern part of
California, I'd be glad to stop by, gratis.

I wonder if that's worth organizing more formally? Some Agile Alliance
program where people could apply for a free process evaluation in
exchange for rights to gather data and publish an anonymized report?

We learn so much from the failures that I'd be glad to contribute some
time to that. And showing that we're concerned about the failures could
be good PR.

> > I think people are especially prone to the this problem when they're
> > used to things running poorly. Perhaps Paul's pal's team feels their
> > current situation is an improvement, even if it fills the rest of us
> > with horror. As the country song goes, "I been down so long, it looks
> > like up to me."
>
> But from what Paul said, it sounds like these people aren't even
> trying a number of the practices. I don't recall whether he's said
> whether they're experiencing anything like improvement over their
> previous situation, or otherwise having fun. His overtones of
> concerns from himself and their manager made me think not, but that
> could be wrong.

Certainly in my first XP adoption, which was out of books, we didn't try
a number of the practices either. It was just too much to change at
once. And looking back, although I thought I was doing merciless
refactoring at the time, I wouldn't agree now.

After a few months, we definitely liked it better. But for a while, we
were just doing some weird-feeling things because the theory was
appealing. And because Martin and Kent on stage came across as smart and
sensible enough that we couldn't dismiss it out of hand as madness.

> I'd think that the things he /has/ mentioned would be red flags. I'd
> really like to see the checklist of which practices they are doing.

Heh. The same thing also applies to all of the RUP adoptions I've
personally seen, but that didn't slow 'em down much there, either. :-)

I certainly share your shock. But for reasons I can't quite articulate,
I'm not particularly surprised. Hopefully they're kinda far out at the
ugly end of the XP adoption bell curve, though.

William

--
William Pietri <william@...>

Kay A. Pentecost wrote:

> I've been thinking a lot about new bugs that appear when old bugs are fixed.

[TTTO "Turn Turn Turn" by the Byrds]

To every bug (churn churn churn)
There is a reason (churn churn churn)
And a source for every bug in the bugbase.

A bug to leak memory
A bug to trash drives
A bug to overflow
A bug to mismatch

..and so on...

--
   Phlip
   http://www.c2.com/cgi/wiki?ZeekLand

John Carter wrote:

> Most Amazing and Attention Getting Line should be first in a program,
> told as a story.

"The first line of a program should 'hook' the computer, and make it
'care' about the program" --Dan Twedt

--
   Phlip
   http://www.c2.com/cgi/wiki?ZeekLand

> I both agree and disagree with this. My point was about project
> management, not about either software construction or group process.
> I will grant you that there are differences between XP and Scrum in
> the project management area, but those differences are overwhelmed
> by the similarities.

John,

Can you explain some more about what you see as the distinction
between group process and project management? For me, I think of
project management as an aspect of group process. This seems
especially true for processes like Scrum.

> The real significant differences are that XP has a software construction
> process, and none of the others do. XP has gone farther into the group
> process than any of the others as well.

Maybe this statement will be more clear when you describe your view
of group process. Also, how do you define "gone farther into"? Do you
mean, for example, more prescriptive practices versus more focus on
self-organization with less predefined structure?

I see a difference in the way XP and Scrum approach the goal of
agile development. Mike Beedle refers to Scrum teams as "intelligent,
autonomous, self-interested, self-organizing multi-agents". The
XP founders appear to have motivated by different perspectives
that were more focused on communication and relationships between
people. I believe both views are valuable and overlapping
perspectives on agility. The overlap would explain why XP and Scrum
teams often adopt practices from both processes to suit their
particular needs.

Regards,

Steve

----- Original Message -----
From: "Steve Bate" <steve.at.technoetic.com@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Monday, August 01, 2005 9:35 AM
Subject: RE: [XP] Shifting of the Balance?


>> I both agree and disagree with this. My point was about project
>> management, not about either software construction or group process.
>> I will grant you that there are differences between XP and Scrum in
>> the project management area, but those differences are overwhelmed
>> by the similarities.
>
> John,
>
> Can you explain some more about what you see as the distinction
> between group process and project management? For me, I think of
> project management as an aspect of group process. This seems
> especially true for processes like Scrum.

Project management is macro, group process is micro.

To expand on that rather obscure statement: project management is
about breaking the project into schedulable units of work and reporting
on the results. Group process is about how the people on the project
team interact all the time.

Agile project management has a way of doing this that is quite distinct
from, for example, either classical software engineering or classical
waterfall, and that is easily recognizable regardless of the label you slap
on the methodology.

XP's small, colocated group process is about the engineering process
(shared code ownership, osmotic communication, pair programming)
as much as it is about project management. XP has never attempted to
formally define other ways of organizing the team. XP for One avoids
real issues of what you do when you can't pair - and those are very
significant quality and creativity issues. On the other end, XP also
avoids dealing with projects that are too large for one small, colocated
team or that are, of necessity, distributed across the face of the planet.
And what about XP and Open Source, where the people working on
the project are individuals scattered over the face of the planet?

That's the way I see it, anyway.

John Roth

>> The real significant differences are that XP has a software construction
>> process, and none of the others do. XP has gone farther into the group
>> process than any of the others as well.
>
> Maybe this statement will be more clear when you describe your view
> of group process. Also, how do you define "gone farther into"? Do you
> mean, for example, more prescriptive practices versus more focus on
> self-organization with less predefined structure?

You have to start somewhere. Prescriptive practices are for learning.
Once you've ascended far enough on the learning curve, you will know
what really makes a difference and what can be swapped out and
substituted.

> I see a difference in the way XP and Scrum approach the goal of
> agile development. Mike Beedle refers to Scrum teams as "intelligent,
> autonomous, self-interested, self-organizing multi-agents". The
> XP founders appear to have motivated by different perspectives
> that were more focused on communication and relationships between
> people. I believe both views are valuable and overlapping
> perspectives on agility. The overlap would explain why XP and Scrum
> teams often adopt practices from both processes to suit their
> particular needs.

Scrum is more interested in autonomy, XP is more interested
in productivity. All else comes from that very basic uber-value
difference, which it took Alistair Cockburn to point out to me.
See the discussion at the back of Crystal Clear.

John Roth

>
> Regards,
>
> Steve

On Monday, August 1, 2005, at 10:39:01 AM, Joshua Kerievsky wrote:

>>Hmm. "Storytests". A new word. I can think of some advantages to
>>that, I guess ...
>>
>>
> Ron -- I invented that word back in 2003 to communicate the connection
> between tests and stories.  I'm surprised you haven't run across it
> before -- "storytesting" is a practice in IXP, as is SDD, which stands
> for storytest-driven development.

I have run across it. I was reflecting on the advantages, and dis,
of coining a new "word" rather than a phrase ...

Ron Jeffries
www.XProgramming.com
2 + 2 = 5, for sufficiently large values of 2.

On Monday, August 1, 2005, at 11:35:35 AM, Steve Bate wrote:

> I see a difference in the way XP and Scrum approach the goal of
> agile development. Mike Beedle refers to Scrum teams as "intelligent,
> autonomous, self-interested, self-organizing multi-agents". The
> XP founders appear to have motivated by different perspectives
> that were more focused on communication and relationships between
> people. I believe both views are valuable and overlapping
> perspectives on agility. The overlap would explain why XP and Scrum
> teams often adopt practices from both processes to suit their
> particular needs.

Hmm ...

I would say that Beedle's terms apply to XP teams, and in fact to
any collection of people, not just to Scrum ...

It has seemed to me, sometimes, that XP defines a fairly decent
starting point for a project, namely a set of practices that is safe
enough to get you delivering software, and from which a team can
figure out what they really need to do. We often see Scrum teams who
don't have much in the way of engineering practices, and who wind up
thrashing, or getting "mostly done" instead of done. I think that
XP's practices make that much less likely.

As for adopting and adapting practices, there are surely hundreds of
useful practices and techniques in software development, not just
one or two dozen. I would think and trust that any thoughtful team
would be looking at all the practices they know of, and assessing
whether they fit their needs.

That's part of why, to me, XP may look at first like it might be a
definition of a "point" in software development space, but that it
really defines a large volume, because it can be, will be, and
should be customized to the situation.

Ron Jeffries
www.XProgramming.com
Steering is more important than speed,
in driving and in software development.

On Monday, August 1, 2005, at 8:15:44 AM, Matt Secoske wrote:

> I have always seen debugging as an iterative process. You fix a bug and
> potentially find a bug/s. With TDD, (something I am just now getting my head
> around) I would imagine that there are still times when you need to invoke
> the debugger and walk through the code. However, I would image that this
> happens quite a bit later in the process than in a code-fix environement, as
> you have the tests to back you up.

Today, I consider it a "failure" if I need to use the debugger. I
try to push a bit to find ways to find out what I need to know
without it. Those ways usually entail writing a test.

I find that when I do TDD in tiny steps, I "need" the debugger far
less often, primarily because my code comes out much simpler than it
used to, and because I test each code branch as I write it, rather
than later, if at all.

> So, you fix a bug an break 20 tests... at least you know that they are
> broke, instead of having to run the code through any number of machinations
> to "test" it. Is this how you have seen TDD work?

Well, yes ... but I think that I also see that breaking many tests
happens, not because the code is complex, but because the initial
change was bad for any purpose. My TDD'd code is much more modular,
and generally speaking, changes tend to be localized and not to have
wide-spread effects.

Can you sense similar things happening when you TDD?

Ron Jeffries
www.XProgramming.com
If you want to garden, you have to bend down and touch the soil.
Gardening is a practice, not an idea.
   -- Thich Nhat Hanh