My quote was somewhat incomplete. I did it on the top of my memory;
I'm writing from the book, now:

(( page 187, talking about Planning Extreme Programming ))

"When viewed as a set of RM (( not sure if he means Risk Management or
Risk Mitigation )) stratedies, XP makes all kinds of sense. The
two-week planning and delivery cycle determined by the customer is a
built-in risk-mitigation strategy with customer-defined value and is
designed to prevent late delivery."

I think we are talking more about risk-mitigation, therefore.

Regards
Marco

On Sun, Aug 31, 2008 at 8:18 PM, paul grew <paul.grew@...> wrote:
> what risk management tools does XP have?
>
> Marco Bizzarri wrote:
>>
>> I read the book maybe two years ago; I liked it a lot.
>>
>> It proposes a method which should be adaptable enough to be used in
>> many contexts.
>>
>> It has a bibliography on Risk Management topic; you cannot apply it
>> directly to XP or Agile, I think, but it acknowledge XP has inherently
>> built-in risk management tools, so that it can be easily adapted to
>> it.
>>
>> I wonder what are the things missing from this book. Can you share
>> some thoughts?
>>
>> Regards
>> Marco
>>
>> On Sun, Aug 31, 2008 at 1:26 PM, Simon Kirk
>> <extremeprogramming@...
>> <mailto:extremeprogramming%40simonkirk.com>> wrote:
>> > Hi all.
>> >
>> > Since my stack of Agile/Lean/etc books to read has recently got
>> > dangerously close to less than six feet tall, I thought I would add a
>> > few more. One area in particular I'm interested in learning more about
>> > is software Risk management.
>> >
>> > Having read Slack already, and loving Lister & DeMarco's style (I know
>> > Slack was only by Tom DeMarco, but still), I thought I would grab a
>> > copy of Waltzing with Bears.
>> >
>> > Having a brief look through the reviews on Amazon (and applying the
>> > usual pinch of salt), some reviews on the UK site (I'm in the UK)
>> > seemed to indicate that WwB was lacking a few things. The US site's
>> > reviews were a bit more positive, but still it made me take notice.
>> >
>> > Can anybody back this up or deny it? I'm going to read the book
>> > anyway, but I'm open to suggestions of other resources to read to
>> > learn more about risk in software, too.
>> >
>> > Cheers for any help.
>> > Simon
>> >
>> > [|]
>> >
>> >
>>
>> --
>> Marco Bizzarri
>> http://notenotturne.blogspot.com/ <http://notenotturne.blogspot.com/>
>> http://iliveinpisa.blogspot.com/ <http://iliveinpisa.blogspot.com/>
>>
>>
>
> --
>
> <http://11thhourfilm.com>
>
>



--
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/

On Sun, Aug 31, 2008 at 9:32 PM, Simon Kirk
<extremeprogramming@...> wrote:
> David, Marco, thanks for the pointers.
>
> Marco: I haven't read the book yet unfortunately. The reviews seemed
> to indicate:
>
> 1. A lack of rigourous mathematical examination of the Risk strategies
> in the book (personally I think that would be massive overkill)

Mumble mumble... my days in statistical and probabilistic analysys are
very far in the past ;),but I felt that the maths was enough for the
purpose of the book.


> 2. While the book mentions Agile, it doesn't examine in detail how it
> mitigates the Risks mentioned in the book.

I think they are too critics on this topic. The book is less than 200
hundred pages long, and, it tries to address the problem. If I could
make a parallel, this is not the GoF for RM.

> I don't see 1 or 2 as disastrous, but not having read the book yet I
> don't even know if 1 and 2 are accurate.

Please share your thoughts with us when you read the book.

> Cheers,
> Simon
>
> On 31 Aug 2008, at 12:41, Marco Bizzarri wrote:
>
>> I read the book maybe two years ago; I liked it a lot.
>>
>> It proposes a method which should be adaptable enough to be used in
>> many contexts.
>>
>> It has a bibliography on Risk Management topic; you cannot apply it
>> directly to XP or Agile, I think, but it acknowledge XP has inherently
>> built-in risk management tools, so that it can be easily adapted to
>> it.
>>
>>
>> I wonder what are the things missing from this book. Can you share
>> some thoughts?
>>
>> Regards
>> Marco
>>
>>
>>
>> On Sun, Aug 31, 2008 at 1:26 PM, Simon Kirk
>> <extremeprogramming@...> wrote:
>>> Hi all.
>>>
>>> Since my stack of Agile/Lean/etc books to read has recently got
>>> dangerously close to less than six feet tall, I thought I would add a
>>> few more. One area in particular I'm interested in learning more
>>> about
>>> is software Risk management.
>>>
>>> Having read Slack already, and loving Lister & DeMarco's style (I
>>> know
>>> Slack was only by Tom DeMarco, but still), I thought I would grab a
>>> copy of Waltzing with Bears.
>>>
>>> Having a brief look through the reviews on Amazon (and applying the
>>> usual pinch of salt), some reviews on the UK site (I'm in the UK)
>>> seemed to indicate that WwB was lacking a few things. The US site's
>>> reviews were a bit more positive, but still it made me take notice.
>>>
>>> Can anybody back this up or deny it? I'm going to read the book
>>> anyway, but I'm open to suggestions of other resources to read to
>>> learn more about risk in software, too.
>>>
>>> Cheers for any help.
>>> Simon
>>>
>>> [|]
>>>
>>>
>>
>>
>>
>> --
>> Marco Bizzarri
>> http://notenotturne.blogspot.com/
>> http://iliveinpisa.blogspot.com/
>>
>> ------------------------------------
>>
>> 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.comYahoo! Groups Links
>>
>>
>>
>
> [|]
>
>



--
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/

I think that the problem in this case is that the test for the corner
case was the first one written and made to pass.

If the "normal" case test was written first, then you would have a lot
easier time justifying the corner case test to yourself, even if you
expected it to be green.

The normal case test is certainly justified, even if not as part of the
TDD process proper. If someone refactors this code later, you certainly
want the normal case to continue working!

--
Bill Michell
Development Team Leader, Broadcast Platforms, BBC FM&T (Journalism).


-----Original Message-----
From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ron Jeffries
Sent: 31 August 2008 23:51
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] how much to unit test function that calls well-tested
functions?

Hello, David.  On Sunday, August 31, 2008, at 1:41:02 PM, you
wrote:

>> How do you know the tests will not fail until you actually write
>> them?

> Yeah, that's a good point.  As is clear, I'm not too worried about
> that specific issue, but, well, I could be wrong.

Um, yes. If we take John's words at face value, we can never stop
writing yet another test. "What if it doesn't work for ... the value
... 3??"

When I'm in the groove, I find that I very rarely need to write a
test just to check that something already works. Either I've been
through that spot already, or I'm sure. (I could be wrong, of
course, and sometimes am, but I think that when the code is really
well crafted, extra tests are usually unnecessary.)

Ron Jeffries


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views
which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Hi John,

Here is the way I see it.
1.    The developer knows what the software should(n't) be doing for the current
development cycle.
2.    Developer writes the tests.
3.    The tests first fail and eventually pass.
4.    Refactoring is considered and acted upon the considerations.
5.    End of development or back to 1.

The way I understand it, what we are discussing now is outside this cycle.  It's
about the insecurity of the developer on whether enough test have been written. 
My point is that it doesn't seem to be a good idea to let these insecurities
freeze the development.  Because we run the automated tests all the time and the
test coverage is quite thorough, and we consider refactoring after each
successful test run, if there is something we missed, it will eventually surface
with enough hints of where it's to be taken care that no meaningful debt will be
incurred.

On the other hand, if we base our decisions on fear and ignorance, there is no
guarantee as related to the quality of our decisions.  This doesn't mean to
impose a prohibition about pondering on whether the test coverage is enough. 
Pondering is always good, but this should be a parallel activity, not one in
series within the development process, because if it is in series it threatens
the progress of the project.  Additionally, each refactoring opportunity is also
an opportunity to reconsider the test coverage at the current development point.
However, in this case adding or deleting tests should be based on the clear
perception of a need, not a vague pondering.  The pondering is the motivator for
critical observation, the clear perception of the need is the trigger for
action.

Victor

===================================

   ----- Original Message -----
   From: John A. De Goes
   To: extremeprogramming@yahoogroups.com
   Sent: Sunday, August 31, 2008 6:41 PM
   Subject: Re: [XP] how much to unit test function that calls well-tested
functions?



   By that illogic, you shouldn't write any automated tests. When you
   have "problems" in the future, you can solve them -- by debugging!

   Of course that's absurd. Code that isn't covered by automated tests is
   junk code with high technical debt. Sometimes we have to write it, but
   we prefer to avoid it because of the high cost of interest payments on
   that debt.

   Regards,

   John A. De Goes
   N-BRAIN, Inc.
   http://www.n-brain.net
   [n minds are better than n-1]

   On Aug 31, 2008, at 4:17 PM, Victor wrote:

   > Hi David C.
   >
   > > I am worried about having the tests not being rich enough to support
   > future refactoring, ...
   >
   > This sounds a little like BDUP. If there are problems in the future,
   > solve them in the future. This is what drives the development, the
   > TDD - refactoring dynamics.
   >
   > If after some refactoring you start seeing red flags, there will
   > also be information about the location and nature of the problem.
   > Then hopefully you'll know enough to solve it. At least more than now.
   >
   > Victor.
   >
   > ======================================
   >
   > ----- Original Message -----
   > From: David Carlton
   > To: extremeprogramming@yahoogroups.com
   > Sent: Sunday, August 31, 2008 1:41 PM
   > Subject: Re: [XP] how much to unit test function that calls well-
   > tested functions?
   >
   > On Sat, 30 Aug 2008 18:10:13 -0600, "John A. De Goes" <john@...
   > > said:
   >
   > > How do you know the tests will not fail until you actually write
   > > them?
   >
   > Yeah, that's a good point. As is clear, I'm not too worried about
   > that specific issue, but, well, I could be wrong. And,
   >
   > > I'll come down on the opposite side of the fence and say you're not
   > > done writing tests until all the behavior you need is specified in
   > the
   > > tests. You haven't reached that point yet, so you're job is not
   > done.
   >
   > > Very often in TDD a very beautiful abstraction arises that gives you
   > > much more than you asked for. I don't stop writing tests, however,
   > > until the tests encode all the behavior I need -- even if writing
   > them
   > > is nothing more than a successive series of GREENs.
   >
   > I am worried about having the tests not being rich enough to support
   > future refactoring, which ties in with the above.
   >
   > > Now you do bring up a valid point: since moveBefore() is implemented
   > > in terms of remove() and insert(), your tests for moveBefore() will
   > > likely duplicate logic with your tests for remove() and insert().
   > > That's OK -- you can factor out the duplication as you see a pattern
   > > emerging. My test suites tend to look like DSLs because they push
   > > duplicated logic into helper methods.
   >
   > Huh, interesting idea, I'll think about that.
   >
   > David Carlton
   > carlton@...
   >
   > [Non-text portions of this message have been removed]
   >
   >
   >

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





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

Hello, John.  On Monday, September 1, 2008, at 1:00:09 AM, you
wrote:

> I think a good rule of thumb is one test for every code path.

Yes. Seems to me that TDD done at all carefully does that.

> Otherwise, the tests poorly specify the behavior of the code, and
> negative changes to the code will not necessarily be caught by
> automated tests. Which basically means no one can know if refactoring
> breaks anything.

> This Fear, Uncertainty, and Doubt leads to some nasty combination of
> defects, code rot, technical debt, and an inability to respond to
> changing requirements.

Certainly. Don't do that, that's my advice. :)

Ron Jeffries
www.XProgramming.com
Ron gave me a good suggestion once. -- Carlton (banshee858)

Hello, John.  On Monday, September 1, 2008, at 1:14:24 AM, you
wrote:

> Say you're finishing up a contract job, and know that you won't be
> responsible for maintaining the software in the future. Do you come
> out ahead or behind by incurring technical debt?

I don't think so. Not if it has to work. If it doesn't have to work,
as Chet puts it, we are done now.

> Or suppose you're part of a start-up, and the VC firm is demanding a
> feature-complete release in six weeks, or will cut off funding. Is it
> OK to borrow from the future a little to keep your job?

I don't think so. I don't think features come out faster when we
write crappy code. I think we just feel like it must be better
because we're hurrying.

What I /would/ do would be cut out the frills. But if the code has
to work, writing it ugly doesn't make that more likely.

> I think in some cases, you come out ahead by incurring technical debt,
> just like in real-life you sometimes come out ahead by borrowing. It's
> a gamble, of course, but sometimes the risk-takers actually do beat
> the risk-minimizers.

Over a day, maybe. Over a week, I think it's not the way to bet.
There is one possible exception that I can think of, some kind of
rape and paste approach to a million web pages.

But even then, since the bastards are going to ask for a change,
extracting the code into functions is probably still going to win.

I don't know how to do an experiment that we could believe. But I've
been coding in various ways and paying attention for a long time
now, and I have never failed to get in trouble when I wrote crap.

Ron Jeffries
www.XProgramming.com
Ron gave me a good suggestion once. -- Carlton (banshee858)

Hi Victor,

The point is that if your code *relies* on a method to behave a
certain way, then your intention and the consequent code dependencies
should be documented in an automated test.

Otherwise, if the code changes, running automated tests will not
detect the broken assumption, nor the affected code.

If you don't care how a method behaves (with respect to a certain
aspect), then by all means, stop testing. But if you've written 40% of
your tests and suddenly come to believe that the code will pass the
other 60% without any additional effort, you should NOT stop writing
tests until the behavior you need and will come to depend on is
captured in automated tests.

Whether or not you call that "TDD" is up to you.

Note you don't have to be subjective, if you'd rather not. Tools like
Jumble will mutate your code and run the automated tests, and tell you
how many mutations are detected by one or more failed test cases.

Regards,

John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]

On Sep 1, 2008, at 4:41 AM, Victor wrote:

> Hi John,
>
> Here is the way I see it.
> 1. The developer knows what the software should(n't) be doing for
> the current development cycle.
> 2. Developer writes the tests.
> 3. The tests first fail and eventually pass.
> 4. Refactoring is considered and acted upon the considerations.
> 5. End of development or back to 1.
>
> The way I understand it, what we are discussing now is outside this
> cycle. It's about the insecurity of the developer on whether enough
> test have been written. My point is that it doesn't seem to be a
> good idea to let these insecurities freeze the development. Because
> we run the automated tests all the time and the test coverage is
> quite thorough, and we consider refactoring after each successful
> test run, if there is something we missed, it will eventually
> surface with enough hints of where it's to be taken care that no
> meaningful debt will be incurred.
>
> On the other hand, if we base our decisions on fear and ignorance,
> there is no guarantee as related to the quality of our decisions.
> This doesn't mean to impose a prohibition about pondering on whether
> the test coverage is enough. Pondering is always good, but this
> should be a parallel activity, not one in series within the
> development process, because if it is in series it threatens the
> progress of the project. Additionally, each refactoring opportunity
> is also an opportunity to reconsider the test coverage at the
> current development point. However, in this case adding or deleting
> tests should be based on the clear perception of a need, not a vague
> pondering. The pondering is the motivator for critical observation,
> the clear perception of the need is the trigger for action.
>
> Victor
>

On Sep 1, 2008, at 6:15 AM, Ron Jeffries wrote:
> Hello, John. On Monday, September 1, 2008, at 1:00:09 AM, you
> wrote:
>
> > I think a good rule of thumb is one test for every code path.
>
> Yes. Seems to me that TDD done at all carefully does that.
>


Agreed. I start from there and add more test cases when I know I need
behavior that isn't captured in any existing test case.

Regards,

John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]

I really think coding without automated tests is like gambling.
Sometimes you come out ahead, but most times you go broke. The exact
percentage depends not just on luck (as for gambling), but on
programmer skill, language choice, tool set, and so forth.

I think that's what makes it addictive for many developers. Sometimes
you write 1000 lines of code and it works perfectly the first go,
without TDD and without debugging. In these cases, you clearly come
out ahead by not writing tests, assuming the code will never be
changed by anyone ever again (an assumption that is wrong in most
cases -- but how wrong depends on the lifespan of the application).

TDD and automated testing represent the strategy of minimizing
variance: the pace is slow and steady and surprises are few and far
between. They also represent the strategy of minimizing technical
debt, which easily pays for itself and then some, but only over a
sufficiently long time frame.

Some years ago in the gaming industry, it was well-known that most
titles lost money, and those costs were born by the occasional
blockbuster (I believe this is still true in the movie industry). A
very lucky win can cover your losses. Sometimes I wonder if many
software development companies survive on the same principle. Produce
crap at full steam ahead. Most of the times the project will end
badly, but occasionally you'll get lucky and save a bundle. Enough to
make up for the losses? Perhaps, since many chop shops don't have to
maintain the crap they produce.

Regards,

John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]

On Sep 1, 2008, at 6:19 AM, Ron Jeffries wrote:

> Hello, John. On Monday, September 1, 2008, at 1:14:24 AM, you
> wrote:
>
> > Say you're finishing up a contract job, and know that you won't be
> > responsible for maintaining the software in the future. Do you come
> > out ahead or behind by incurring technical debt?
>
> I don't think so. Not if it has to work. If it doesn't have to work,
> as Chet puts it, we are done now.
>
> > Or suppose you're part of a start-up, and the VC firm is demanding a
> > feature-complete release in six weeks, or will cut off funding. Is
> it
> > OK to borrow from the future a little to keep your job?
>
> I don't think so. I don't think features come out faster when we
> write crappy code. I think we just feel like it must be better
> because we're hurrying.
>
> What I /would/ do would be cut out the frills. But if the code has
> to work, writing it ugly doesn't make that more likely.
>
> > I think in some cases, you come out ahead by incurring technical
> debt,
> > just like in real-life you sometimes come out ahead by borrowing.
> It's
> > a gamble, of course, but sometimes the risk-takers actually do beat
> > the risk-minimizers.
>
> Over a day, maybe. Over a week, I think it's not the way to bet.
> There is one possible exception that I can think of, some kind of
> rape and paste approach to a million web pages.
>
> But even then, since the bastards are going to ask for a change,
> extracting the code into functions is probably still going to win.
>
> I don't know how to do an experiment that we could believe. But I've
> been coding in various ways and paying attention for a long time
> now, and I have never failed to get in trouble when I wrote crap.
>
> Ron Jeffries
> www.XProgramming.com
> Ron gave me a good suggestion once. -- Carlton (banshee858)
>

Hi John,

I am afraid we understand differently what I wrote.

>    The point is that if your code *relies* on a method to behave a
certain way, then your intention and the consequent code dependencies
should be documented in an automated test.

No problem with that.  If the code *relies*, then it's part of the requirements
for the current development cycle, and it should not be a problem to write the
corresponding test.  What I am relating to is a case where the situation is more
nebulous, things are not clear, and the developer does not know how to proceed. 
If you don't know how to proceed, it's because either there is no requirement,
or the requirement is not clear. Then either clarify the requirement or if you
can't, proceed to the next existing one.  That's all.

Víctor

===============================================


   ----- Original Message -----
   From: John A. De Goes
   To: extremeprogramming@yahoogroups.com
   Sent: Tuesday, September 02, 2008 5:10 PM
   Subject: Re: [XP] how much to unit test function that calls well-tested
functions?



   Hi Victor,

   The point is that if your code *relies* on a method to behave a
   certain way, then your intention and the consequent code dependencies
   should be documented in an automated test.

   Otherwise, if the code changes, running automated tests will not
   detect the broken assumption, nor the affected code.

   If you don't care how a method behaves (with respect to a certain
   aspect), then by all means, stop testing. But if you've written 40% of
   your tests and suddenly come to believe that the code will pass the
   other 60% without any additional effort, you should NOT stop writing
   tests until the behavior you need and will come to depend on is
   captured in automated tests.

   Whether or not you call that "TDD" is up to you.

   Note you don't have to be subjective, if you'd rather not. Tools like
   Jumble will mutate your code and run the automated tests, and tell you
   how many mutations are detected by one or more failed test cases.

   Regards,

   John A. De Goes
   N-BRAIN, Inc.
   http://www.n-brain.net
   [n minds are better than n-1]

   On Sep 1, 2008, at 4:41 AM, Victor wrote:

   > Hi John,
   >
   > Here is the way I see it.
   > 1. The developer knows what the software should(n't) be doing for
   > the current development cycle.
   > 2. Developer writes the tests.
   > 3. The tests first fail and eventually pass.
   > 4. Refactoring is considered and acted upon the considerations.
   > 5. End of development or back to 1.
   >
   > The way I understand it, what we are discussing now is outside this
   > cycle. It's about the insecurity of the developer on whether enough
   > test have been written. My point is that it doesn't seem to be a
   > good idea to let these insecurities freeze the development. Because
   > we run the automated tests all the time and the test coverage is
   > quite thorough, and we consider refactoring after each successful
   > test run, if there is something we missed, it will eventually
   > surface with enough hints of where it's to be taken care that no
   > meaningful debt will be incurred.
   >
   > On the other hand, if we base our decisions on fear and ignorance,
   > there is no guarantee as related to the quality of our decisions.
   > This doesn't mean to impose a prohibition about pondering on whether
   > the test coverage is enough. Pondering is always good, but this
   > should be a parallel activity, not one in series within the
   > development process, because if it is in series it threatens the
   > progress of the project. Additionally, each refactoring opportunity
   > is also an opportunity to reconsider the test coverage at the
   > current development point. However, in this case adding or deleting
   > tests should be based on the clear perception of a need, not a vague
   > pondering. The pondering is the motivator for critical observation,
   > the clear perception of the need is the trigger for action.
   >
   > Victor
   >





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

A short screencast showing myself and two other developers TDD'ing a
Stack in the Java programming language:

      http://www.vimeo.com/1653402

I think it makes a good introduction to test-driven development,[1]
and shows how following TDD strictly leads to test coverage of all
code paths. You can download the source code from
http://www.n-brain.net/outbox/una-tdd-stack.zip

We used UNA 1.1 and the newly-released Java 5 Mixin for UNA, which
integrates open source tools like Infinitest and JUnit into UNA.

Although we used text chat for this tutorial, if you were doing
serious development, you would likely be collocated or use voice chat.

A note to help you follow along: UNA has been configured so that
whenever a file is saved, the code is compiled, and if compilation is
successful, then the relevant tests are re-run using Infinitest (and
if the compilation is not successful, errors/warnings appear directly
in the offending documents). This happens on all developers' machines,
because the configuration is done via "Team Tools", which are
accessible to all members of the team.

This turns "Save" into a kind of "I think I'm ready" button, where
both the compiler and the automated tests let you know if you really
ARE ready. I highly recommend that UNA be configured in this way with
any language, not just with Java, and we'll be releasing a PHP mixin
in the near future which does just that for PHP (though it's pretty to
easy to do the same for any other language).

Comments are welcome!

[1] The tutorial doesn't really showcase the "design" benefits of TDD,
as stacks are well-defined. A larger or less-well-defined scenario
would better demonstrate design benefits.

John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]

Hi Victor,

Then we may not disagree at all, and would likely both recommend that
David continue writing tests, until the behavior he needs is captured
in the tests.

Regards,

John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]

On Sep 2, 2008, at 3:51 PM, Victor wrote:

> Hi John,
>
> I am afraid we understand differently what I wrote.
>
> > The point is that if your code *relies* on a method to behave a
> certain way, then your intention and the consequent code dependencies
> should be documented in an automated test.
>
> No problem with that. If the code *relies*, then it's part of the
> requirements for the current development cycle, and it should not be
> a problem to write the corresponding test. What I am relating to is
> a case where the situation is more nebulous, things are not clear,
> and the developer does not know how to proceed. If you don't know
> how to proceed, it's because either there is no requirement, or the
> requirement is not clear. Then either clarify the requirement or if
> you can't, proceed to the next existing one. That's all.
>
> Víctor
>

I would say D.  was exposed enough to this discussion.  I would recommend he
decides for himself how to proceed.

Victor

=====================
   ----- Original Message -----
   From: John A. De Goes
   To: extremeprogramming@yahoogroups.com
   Sent: Tuesday, September 02, 2008 7:16 PM
   Subject: Re: [XP] how much to unit test function that calls well-tested
functions?



   Hi Victor,

   Then we may not disagree at all, and would likely both recommend that
   David continue writing tests, until the behavior he needs is captured
   in the tests.

   Regards,

   John A. De Goes
   N-BRAIN, Inc.
   http://www.n-brain.net
   [n minds are better than n-1]

   On Sep 2, 2008, at 3:51 PM, Victor wrote:

   > Hi John,
   >
   > I am afraid we understand differently what I wrote.
   >
   > > The point is that if your code *relies* on a method to behave a
   > certain way, then your intention and the consequent code dependencies
   > should be documented in an automated test.
   >
   > No problem with that. If the code *relies*, then it's part of the
   > requirements for the current development cycle, and it should not be
   > a problem to write the corresponding test. What I am relating to is
   > a case where the situation is more nebulous, things are not clear,
   > and the developer does not know how to proceed. If you don't know
   > how to proceed, it's because either there is no requirement, or the
   > requirement is not clear. Then either clarify the requirement or if
   > you can't, proceed to the next existing one. That's all.
   >
   > Víctor
   >





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

On Tue, 02 Sep 2008 19:40:04 -0400, "Victor" <vmgoldberg@...> said:

> I would say D. was exposed enough to this discussion.  I would
> recommend he decides for himself how to proceed.

And I certainly appreciate all the discussion and advice I've gotten!
For now, I'm sticking with two tests for that specific function (a
normal case and the most edge of edge cases), and trusting tests of
other functions (both functions that it calls and functions that call
it) to provide an acceptable web of coverage.

I'm far from sure that this is the best course of action, but I don't
think it's horribly rash; if it eventually proves not to have been the
best course of action, at least that will teach me something about
TDD...

David Carlton
carlton@...

Hi all

Some of my team are forming a study group around (so-called) ping-pong
pairing, meaning one of the pair writes the test, then the keyboard is
swapped, and the other writes the passing code.

Has anybody got any resources, info or whatever about this practice
that they can have a look at for reference?

Cheers,
Simon

[|]

Hello, John.  On Tuesday, September 2, 2008, at 7:12:10 PM, you
wrote:

> A short screencast showing myself and two other developers TDD'ing a
> Stack in the Java programming language:

>      http://www.vimeo.com/1653402

Interesting. Makes me wish we could make UNA work.

However ...

1. You started with about a million lines of code before
    the first test. Or 15.

2. Is there some skipped material? It seemed that a method
    magically appeared without being typed in on the screen.
    But maybe I dozed off.

Definitely interesting. Pretty close to what I'd expect in TDD.
Close enough, in fact.

Neat.

Ron Jeffries
www.XProgramming.com
A lot of preconceptions can be dismissed when you actually
try something out. -- Bruce Eckel

Hi Ron,

On Sep 3, 2008, at 8:03 AM, Ron Jeffries wrote:
> Hello, John. On Tuesday, September 2, 2008, at 7:12:10 PM, you
> wrote:
>
> > A short screencast showing myself and two other developers TDD'ing a
> > Stack in the Java programming language:
>
> > http://www.vimeo.com/1653402
>
> Interesting. Makes me wish we could make UNA work.
>

We have a demo server you can use. It's not designed for production
work, but if you just want to do a little coding here and there, it
would fit the bill.

With the demo server, you would only have to install the client, which
is a breeze and takes all of 60 seconds. No configuration is
necessary, because the client already knows how to find the server.
Let me know if you're interested.

> 1. You started with about a million lines of code before
> the first test. Or 15.
>

Sure. Ordinarily I wouldn't recommend this approach, but a stack is a
very well-defined problem, and we agreed on the methods to develop
beforehand. By writing the signatures upfront, we get that grunt work
out of the way and can focus on the red/green/refactor cycle.

We would have done it differently if either (1) the problem was not
well-defined, or (2) UNA could automatically create missing methods.

> 2. Is there some skipped material? It seemed that a method
> magically appeared without being typed in on the screen.
> But maybe I dozed off.
>

There's no skipped material, but due to the resolution limitations,
sometimes the video pans to one location even though stuff is
happening elsewhere. And with 3 developers, stuff happens quite fast.
For example, I usually inserted the test method, by typing 'test' and
hitting Command + I, which inserts a JUnit test. Usually before I even
finished typing the name of the test, Alex or Misha were busy coding
its innards. Look away for 3 seconds and you could miss a whole method.

> Definitely interesting. Pretty close to what I'd expect in TDD.
> Close enough, in fact.
>
> Neat.
>


Thanks. Your feedback makes me want to do another one on a more open-
ended problem, which would be more representative of TDD in the wild.
It would probably last longer, and therefore have a smaller audience,
but would help showcase the design benefits of TDD.

Regards,

John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]

Simon,

On Wed, Sep 3, 2008 at 5:50 AM, Simon Kirk <extremeprogramming@...
> wrote:

> Hi all
>
> Some of my team are forming a study group around (so-called) ping-pong
> pairing, meaning one of the pair writes the test, then the keyboard is
> swapped, and the other writes the passing code.


I kind of suspect that a study group approach to ping-pong programming is
way overkill, unless the study group is going to try it out before talking
about it. Ping pong is really, really simple. It doesn't need resources
other
than computer with some flavor of unit testing framework installed (though
two keyboards/mice can be helpful for logistical and sanitary reasons).


> Has anybody got any resources, info or whatever about this practice
> that they can have a look at for reference?


http://c2.com/cgi/wiki?PairProgrammingPingPongPattern describes
it quite well on 1/3rd of a page.

The theory behind Ping Pong Programming, as far  as I've seen, is
pretty simple: it keeps both halves of a pair attentive and occupied.
That's been my experience.

Dave


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

This is how we use it pretty much...

http://www.magpiebrain.com/blog/2007/02/13/pairing-pattern-ping-pong-pairing/



On Wed, Sep 3, 2008 at 4:20 PM, Dave Smith <davewsmith@...> wrote:
> Simon,
>
> On Wed, Sep 3, 2008 at 5:50 AM, Simon Kirk <extremeprogramming@...
>> wrote:
>
>> Hi all
>>
>> Some of my team are forming a study group around (so-called) ping-pong
>> pairing, meaning one of the pair writes the test, then the keyboard is
>> swapped, and the other writes the passing code.
>
> I kind of suspect that a study group approach to ping-pong programming is
> way overkill, unless the study group is going to try it out before talking
> about it. Ping pong is really, really simple. It doesn't need resources
> other
> than computer with some flavor of unit testing framework installed (though
> two keyboards/mice can be helpful for logistical and sanitary reasons).
>
>> Has anybody got any resources, info or whatever about this practice
>> that they can have a look at for reference?
>
> http://c2.com/cgi/wiki?PairProgrammingPingPongPattern describes
> it quite well on 1/3rd of a page.
>
> The theory behind Ping Pong Programming, as far as I've seen, is
> pretty simple: it keeps both halves of a pair attentive and occupied.
> That's been my experience.
>
> Dave
>
> [Non-text portions of this message have been removed]
>
>

Cheers Cenk.

On 3 Sep 2008, at 16:26, Cenk Çivici wrote:

> This is how we use it pretty much...
>
> http://www.magpiebrain.com/blog/2007/02/13/pairing-pattern-ping-pong-pairing/
>
>
>
> On Wed, Sep 3, 2008 at 4:20 PM, Dave Smith <davewsmith@...>
> wrote:
>> Simon,
>>
>> On Wed, Sep 3, 2008 at 5:50 AM, Simon Kirk <extremeprogramming@...
>>> wrote:
>>
>>> Hi all
>>>
>>> Some of my team are forming a study group around (so-called) ping-
>>> pong
>>> pairing, meaning one of the pair writes the test, then the
>>> keyboard is
>>> swapped, and the other writes the passing code.
>>
>> I kind of suspect that a study group approach to ping-pong
>> programming is
>> way overkill, unless the study group is going to try it out before
>> talking
>> about it. Ping pong is really, really simple. It doesn't need
>> resources
>> other
>> than computer with some flavor of unit testing framework installed
>> (though
>> two keyboards/mice can be helpful for logistical and sanitary
>> reasons).
>>
>>> Has anybody got any resources, info or whatever about this practice
>>> that they can have a look at for reference?
>>
>> http://c2.com/cgi/wiki?PairProgrammingPingPongPattern describes
>> it quite well on 1/3rd of a page.
>>
>> The theory behind Ping Pong Programming, as far as I've seen, is
>> pretty simple: it keeps both halves of a pair attentive and occupied.
>> That's been my experience.
>>
>> Dave
>>
>> [Non-text portions of this message have been removed]

Hi Dave

On 3 Sep 2008, at 16:20, Dave Smith wrote:

> Simon,
>
> On Wed, Sep 3, 2008 at 5:50 AM, Simon Kirk <extremeprogramming@...
>> wrote:
>
>> Hi all
>>
>> Some of my team are forming a study group around (so-called) ping-
>> pong
>> pairing, meaning one of the pair writes the test, then the keyboard
>> is
>> swapped, and the other writes the passing code.
>
>
> I kind of suspect that a study group approach to ping-pong
> programming is
> way overkill, unless the study group is going to try it out before
> talking
> about it. Ping pong is really, really simple. It doesn't need
> resources
> other
> than computer with some flavor of unit testing framework installed
> (though
> two keyboards/mice can be helpful for logistical and sanitary
> reasons).

Yes, I agree. Trying it out is exactly what the group are going to do.
I was using Study Group in terms of the pattern from Fearless Change,
but really, it's the development team taking a chance to learn
something together.

The two keyboards and mouse approach is something they're ready to
give a go.

But one of the team wanted to try and find something to read in case
somebody else had some wisdom...

>
>
>
>> Has anybody got any resources, info or whatever about this practice
>> that they can have a look at for reference?
>
>
> http://c2.com/cgi/wiki?PairProgrammingPingPongPattern describes
> it quite well on 1/3rd of a page.
>
> The theory behind Ping Pong Programming, as far  as I've seen, is
> pretty simple: it keeps both halves of a pair attentive and occupied.
> That's been my experience.

... which is precisely what you've given me there :)

Thanks for the link, I'll forward it on.

Cheers,
Simon
[|]

Hi all,

Remember JBehave? The mother of all BDD frameworks?

Well, it's still alive. We've just released version 2 - a complete
redesign that we hope will be more usable. We can now write scenarios
in plain text, a la RSpec. Visit http://jbehave.org to find out more.

We'd love to hear feedback from the members of this list. What do you think?

Cheers,
Liz.

--
Elizabeth Keogh
liz@...
liz@...
http://jbehave.org
http://sirenian.livejournal.com

Great webcast, SHORT and concise! Shows the very basics of TDD and of
course also your product (in a way that at least got me interested) :)

Perfect for showing colleges who write unit test but still not test
driven.

My question based on a quick look at the product page is how well UNA
is working for C++ development?

/Kristofer

--- In extremeprogramming@yahoogroups.com, "John A. De Goes"
<john@...> wrote:
>
>
> A short screencast showing myself and two other developers TDD'ing a
> Stack in the Java programming language:
>
>      http://www.vimeo.com/1653402
>
> I think it makes a good introduction to test-driven development,[1]
> and shows how following TDD strictly leads to test coverage of all
> code paths. You can download the source code from
http://www.n-brain.net/outbox/una-tdd-stack.zip
>
> We used UNA 1.1 and the newly-released Java 5 Mixin for UNA, which
> integrates open source tools like Infinitest and JUnit into UNA.
>
> Although we used text chat for this tutorial, if you were doing
> serious development, you would likely be collocated or use voice chat.
>
> A note to help you follow along: UNA has been configured so that
> whenever a file is saved, the code is compiled, and if compilation is
> successful, then the relevant tests are re-run using Infinitest (and
> if the compilation is not successful, errors/warnings appear directly
> in the offending documents). This happens on all developers' machines,
> because the configuration is done via "Team Tools", which are
> accessible to all members of the team.
>
> This turns "Save" into a kind of "I think I'm ready" button, where
> both the compiler and the automated tests let you know if you really
> ARE ready. I highly recommend that UNA be configured in this way with
> any language, not just with Java, and we'll be releasing a PHP mixin
> in the near future which does just that for PHP (though it's pretty to
> easy to do the same for any other language).
>
> Comments are welcome!
>
> [1] The tutorial doesn't really showcase the "design" benefits of TDD,
> as stacks are well-defined. A larger or less-well-defined scenario
> would better demonstrate design benefits.
>
> John A. De Goes
> N-BRAIN, Inc.
> http://www.n-brain.net
> [n minds are better than n-1]
>

--- In extremeprogramming@yahoogroups.com, "Steven Gordon"
<sgordonphd@...> wrote:

> XP itself mitigates many major risks:
>
> Here are some examples:
> * Sustainable Pace reduces the chance of somebody leaving during the
project.
> * Pair programming and Collective Code Ownership reduces the impact if
> somebody does leave during the project.
> * Test Driven Development, Automated Acceptance Tests and Continuous
> Integration sharply reduces the half-life of bugs.
> * Frequent Delivery of working software and On-site Customer reduces
> the chance of developing the wrong software.
> * Frequent Delivery of working software reduces the chance of being
> surprised at what will be delivered on the due date.
> * Frequent Delivery of working software guarantees that working
> software will be available on the due date.
>
> Come to think of it, frequent feedback based on the frequent
> delivery of working software is the best possible risk management
> tool, because if we pay attention, we will see risks coming and be
> able to plan for the ones that are coming using the current
> information at the time.
>
> Compare this to the alternate approach of trying to anticipate all
> possible risks and preparing a plan for each risk at the beginning
> of the project when we have the least accurate information we will
> ever have during the project.  Planning for risks that will never
> happen is a big waste of time and effort.  Making plans for those
> risks based on information that will be inaccurate when the risks
> actually happen is a big waste of time and effort.

I would like to add to this list the following additions.

An XP project has more points in time for the customer to halt
investment. Having the information to make a decision to suspend or
stop a project at two months instead of six months may result in
substantial savings.

In addition, when that investment is halted, the customer does have a
working something. It may not be enough of a something to be
profitable and useful or it may be. And even if it's not completed
enough when a project is halted, it's often in a state where it can be
restarted with minimal waste (for some definitions of waste).

The ability to save by stopping a failed project sooner, having a
product to show for the money that was invested, and being able to
restart from a product with shippable tested functionality, all serve
to manage risk from a mitigation standpoint.

--- In extremeprogramming@yahoogroups.com, "John A. De Goes" wrote:

> Some years ago in the gaming industry, it was well-known that most
> titles lost money, and those costs were born by the occasional
> blockbuster (I believe this is still true in the movie industry).
> A very lucky win can cover your losses. Sometimes I wonder if many
> software development companies survive on the same principle.
> Produce crap at full steam ahead. Most of the times the project
> will end badly, but occasionally you'll get lucky and save a
> bundle. Enough to make up for the losses? Perhaps, since many chop
> shops don't have to  maintain the crap they produce.

This struck me as incredibly funny because it's actually the reason I
write unit tests only flipped around.

I consider 99% of my unit tests worthless. The code that passes them I
probably would have written anyway or something so similar that it
doesn't really matter.

That being said, the 1% of my unit tests that have value have such
value that they more than make up for my typing in the other 99%.

The problem is that I don't I don't know in advance which 1% I need
because everyone I know seems to make mistakes randomly, including me.

...
A monk asked Tozen when he was weighing some flax, "What is Buddha?"
Tozen said, "This flax weighs three pounds.
...

I'm nowhere near as enlightened as Tozen. He remained focused on doing
what he was doing, which was weighing flax. But I'm not that perfect,
and that's why I write unit tests. When we make a mistake I want us to
find out nice and early, not sometime in the middle of the night.

Coding with automated tests is gambling too. If you could have had business
success without the tests, you would likely have gotten results sooner by
eliminating testing (and accelerating delivery may have been critical to
your success). Coding with tests is more sustainable, but sustainability may
not be a critical business success factor. OTOH, gambling on not writing
tests means you're less able to change direction. Each strategy will beat
the other sometimes. As my pappy used to say, "You pays your money and you
takes your chances."

Regards,

Kent Beck
Three Rivers Institute


   _____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of John A. De Goes
Sent: Tuesday, September 02, 2008 2:32 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] how much to unit test function that calls well-tested
functions?




I really think coding without automated tests is like gambling.
Sometimes you come out ahead, but most times you go broke. The exact
percentage depends not just on luck (as for gambling), but on
programmer skill, language choice, tool set, and so forth.

I think that's what makes it addictive for many developers. Sometimes
you write 1000 lines of code and it works perfectly the first go,
without TDD and without debugging. In these cases, you clearly come
out ahead by not writing tests, assuming the code will never be
changed by anyone ever again (an assumption that is wrong in most
cases -- but how wrong depends on the lifespan of the application).

TDD and automated testing represent the strategy of minimizing
variance: the pace is slow and steady and surprises are few and far
between. They also represent the strategy of minimizing technical
debt, which easily pays for itself and then some, but only over a
sufficiently long time frame.

Some years ago in the gaming industry, it was well-known that most
titles lost money, and those costs were born by the occasional
blockbuster (I believe this is still true in the movie industry). A
very lucky win can cover your losses. Sometimes I wonder if many
software development companies survive on the same principle. Produce
crap at full steam ahead. Most of the times the project will end
badly, but occasionally you'll get lucky and save a bundle. Enough to
make up for the losses? Perhaps, since many chop shops don't have to
maintain the crap they produce.

Regards,

John A. De Goes
N-BRAIN, Inc.
http://www.n- <http://www.n-brain.net> brain.net
[n minds are better than n-1]

On Sep 1, 2008, at 6:19 AM, Ron Jeffries wrote:

> Hello, John. On Monday, September 1, 2008, at 1:14:24 AM, you
> wrote:
>
> > Say you're finishing up a contract job, and know that you won't be
> > responsible for maintaining the software in the future. Do you come
> > out ahead or behind by incurring technical debt?
>
> I don't think so. Not if it has to work. If it doesn't have to work,
> as Chet puts it, we are done now.
>
> > Or suppose you're part of a start-up, and the VC firm is demanding a
> > feature-complete release in six weeks, or will cut off funding. Is
> it
> > OK to borrow from the future a little to keep your job?
>
> I don't think so. I don't think features come out faster when we
> write crappy code. I think we just feel like it must be better
> because we're hurrying.
>
> What I /would/ do would be cut out the frills. But if the code has
> to work, writing it ugly doesn't make that more likely.
>
> > I think in some cases, you come out ahead by incurring technical
> debt,
> > just like in real-life you sometimes come out ahead by borrowing.
> It's
> > a gamble, of course, but sometimes the risk-takers actually do beat
> > the risk-minimizers.
>
> Over a day, maybe. Over a week, I think it's not the way to bet.
> There is one possible exception that I can think of, some kind of
> rape and paste approach to a million web pages.
>
> But even then, since the bastards are going to ask for a change,
> extracting the code into functions is probably still going to win.
>
> I don't know how to do an experiment that we could believe. But I've
> been coding in various ways and paying attention for a long time
> now, and I have never failed to get in trouble when I wrote crap.
>
> Ron Jeffries
> www.XProgramming.com
> Ron gave me a good suggestion once. -- Carlton (banshee858)
>






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

I wanted to let this cool before replying. I didn't give up metaphor. I
agree with Lakoff and Johnson that all abstract thought is metaphorical and
grounded in our physical experience. However, I don't know how to write a
brief treatment of metaphors in programming that will be useful.

A recent example of the value of metaphor is the switch in JUnit 4 from an
object-oriented framework (where you subclass and override) to a domain
specific language. This has extended, in the latest release, to an embedded
domains specific language for running tests. Folks who want to run tests in
a different way can express their extended behavior in terms of new
"statments" which get inserted into a "block".

Regards,

Kent Beck
Three Rivers Institute

   _____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of aacockburn
Sent: Monday, August 04, 2008 10:29 AM
To: extremeprogramming@yahoogroups.com
Subject: [XP] Re: metaphors



--- In extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com, "S M Kripanidhi"
<kripanidhi@...> wrote:
> I find this key practice in XP very useful to me and this
> practice has
> added most value to me, to my career, to my business, to my
> customers,
> to my teams and to my projects. No other XP Practice added
> as much
> value to me as did Metaphor, as a practice.
>
> Most in the XP community felt that this was the lowest value
> practice
> and may be even Kent Beck got carried away and ignored it
> completely
> in his XP Version 2. When I read XP V2, I felt very sad not
> seeing
> the mention of Metaphor.
>
> I can provide at least 40 live project instances where the use
> of
> Metaphor, as a practice, resulted in a minimum of USD 10,000
> in direct
> savings on the project
>
> I hope others empathize with me.
>
> Kripanidhi

Kent gave it up partly for lack of examples (I recall, perhaps it
was XP 2002, when he said, "This is my last attempt to explain
metaphor. If it doesn't work, I'll drop it.")

If you've done some number of projects using Metaphor, can
you please provide examples of what some of the metaphors were?
That would be very valuable.

thanks - Alistair






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

i agree with everything everyone has said about risk mitigation and
Steven's comment about not bothering to mitigate irrelevant risks is a
great example of YAGNI.
but if the traditional approach to risk analysis is
     get a list of typical project risks
     add some of your own
     work out the probability of each occurring
     work out the impact for each
     design a plan for how to avoid it or what to do if it happens
     then forget about it (excuse my sarcasm)

then what's the agile or XP approach? is this what folks do?
     brainstorm what would really screw up the project
     add some tasks to the release plan or change some behaviour of the team
     repeat based on feed back each iteration


Ken Boucher wrote:
>
> --- In extremeprogramming@yahoogroups.com
> <mailto:extremeprogramming%40yahoogroups.com>, "Steven Gordon"
> <sgordonphd@...> wrote:
>
> > XP itself mitigates many major risks:
> >
> > Here are some examples:
> > * Sustainable Pace reduces the chance of somebody leaving during the
> project.
> > * Pair programming and Collective Code Ownership reduces the impact if
> > somebody does leave during the project.
> > * Test Driven Development, Automated Acceptance Tests and Continuous
> > Integration sharply reduces the half-life of bugs.
> > * Frequent Delivery of working software and On-site Customer reduces
> > the chance of developing the wrong software.
> > * Frequent Delivery of working software reduces the chance of being
> > surprised at what will be delivered on the due date.
> > * Frequent Delivery of working software guarantees that working
> > software will be available on the due date.
> >
> > Come to think of it, frequent feedback based on the frequent
> > delivery of working software is the best possible risk management
> > tool, because if we pay attention, we will see risks coming and be
> > able to plan for the ones that are coming using the current
> > information at the time.
> >
> > Compare this to the alternate approach of trying to anticipate all
> > possible risks and preparing a plan for each risk at the beginning
> > of the project when we have the least accurate information we will
> > ever have during the project. Planning for risks that will never
> > happen is a big waste of time and effort. Making plans for those
> > risks based on information that will be inaccurate when the risks
> > actually happen is a big waste of time and effort.
>
> I would like to add to this list the following additions.
>
> An XP project has more points in time for the customer to halt
> investment. Having the information to make a decision to suspend or
> stop a project at two months instead of six months may result in
> substantial savings.
>
> In addition, when that investment is halted, the customer does have a
> working something. It may not be enough of a something to be
> profitable and useful or it may be. And even if it's not completed
> enough when a project is halted, it's often in a state where it can be
> restarted with minimal waste (for some definitions of waste).
>
> The ability to save by stopping a failed project sooner, having a
> product to show for the money that was invested, and being able to
> restart from a product with shippable tested functionality, all serve
> to manage risk from a mitigation standpoint.
>
>

--

<http://11thhourfilm.com>

Dear Paul,

The strategy you outline below seems like a reasonable idea. It should be
possible to do this in a way that harmonizes with XP. The problems I can
imagine would come if risk management were done contrary to the values of
XP. For example, if you were so worried about risks that you sat around
thinking about them for a long time instead of going out and getting
experience with them (and, hopefully, eliminating the cheap ones).

Regards,

Kent Beck
Three Rivers Institute

   _____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of paul grew
Sent: Wednesday, September 03, 2008 10:59 AM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Software Risk - books help request



i agree with everything everyone has said about risk mitigation and
Steven's comment about not bothering to mitigate irrelevant risks is a
great example of YAGNI.
but if the traditional approach to risk analysis is
get a list of typical project risks
add some of your own
work out the probability of each occurring
work out the impact for each
design a plan for how to avoid it or what to do if it happens
then forget about it (excuse my sarcasm)

then what's the agile or XP approach? is this what folks do?
brainstorm what would really screw up the project
add some tasks to the release plan or change some behaviour of the team
repeat based on feed back each iteration

Ken Boucher wrote:
>
> --- In extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
> <mailto:extremeprogramming%40yahoogroups.com>, "Steven Gordon"
> <sgordonphd@...> wrote:
>
> > XP itself mitigates many major risks:
> >
> > Here are some examples:
> > * Sustainable Pace reduces the chance of somebody leaving during the
> project.
> > * Pair programming and Collective Code Ownership reduces the impact if
> > somebody does leave during the project.
> > * Test Driven Development, Automated Acceptance Tests and Continuous
> > Integration sharply reduces the half-life of bugs.
> > * Frequent Delivery of working software and On-site Customer reduces
> > the chance of developing the wrong software.
> > * Frequent Delivery of working software reduces the chance of being
> > surprised at what will be delivered on the due date.
> > * Frequent Delivery of working software guarantees that working
> > software will be available on the due date.
> >
> > Come to think of it, frequent feedback based on the frequent
> > delivery of working software is the best possible risk management
> > tool, because if we pay attention, we will see risks coming and be
> > able to plan for the ones that are coming using the current
> > information at the time.
> >
> > Compare this to the alternate approach of trying to anticipate all
> > possible risks and preparing a plan for each risk at the beginning
> > of the project when we have the least accurate information we will
> > ever have during the project. Planning for risks that will never
> > happen is a big waste of time and effort. Making plans for those
> > risks based on information that will be inaccurate when the risks
> > actually happen is a big waste of time and effort.
>
> I would like to add to this list the following additions.
>
> An XP project has more points in time for the customer to halt
> investment. Having the information to make a decision to suspend or
> stop a project at two months instead of six months may result in
> substantial savings.
>
> In addition, when that investment is halted, the customer does have a
> working something. It may not be enough of a something to be
> profitable and useful or it may be. And even if it's not completed
> enough when a project is halted, it's often in a state where it can be
> restarted with minimal waste (for some definitions of waste).
>
> The ability to save by stopping a failed project sooner, having a
> product to show for the money that was invested, and being able to
> restart from a product with shippable tested functionality, all serve
> to manage risk from a mitigation standpoint.
>
>

--

<http://11thhourfilm <http://11thhourfilm.com> .com>






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

Hello,
 
In case someone would like to visit south america and practice their spanish,
there is an agile conference that will take place in Argentina in october this
year. Registrations for the conference are now open.
 
Subject: Ágiles 2008 Conference - Register now!

Registration is now open for Ágiles 2008 to be held 22-23 October 2008 at the
Bauen Hotel in Buenos Aires, Argentina.

Ágiles 2008 aims to be a meeting point for IT professionals in the region
interested in sharing their experiences, and discussing and learning on software
development-related topics using Agile methodologies.

Among the international guests who will participate in Ágiles 2008 are Matt
Gelbwaks, Dave Nicolette, Tobias Mayer and the keynote speakers Mary and Tom
Poppendieck.

The conference features talks, interactive sessions, workshops and open space
sessions.

Ágiles 2008 is  free of charge, although prior registration is required. You can
find the registration form in http://www.agiles2008.org/en/registracion.php

More information related with the event, program and venue in www.agiles2008.org

Do not hesitate to contact us at info@...


Ágiles 2008 Organization Team
www.agiles2008.org

[Platinum Sponsors]
Intel, Sabre Holding

[Gold Sponsors]
Three Melons, VersionOne, Microsoft

[Silver Sponsor]
Baufest, Hexacta, Liveware

[Institutional]
Scrum Alliance, IEEE, SADIO, Agile Alliance,
Polo Tecnológico Rosario, Córdoba Technology,
Cessi Argentina















      
________________________________________________________________________________\
____
Yahoo! MTV Blog & Rock >¡Cuéntanos tu historia, inspira una canción y gánate
un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/

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