headers
Laurent Bossavit | 1 Apr 2002 01:00

RE: Ask the Customer

> > I really, really have trouble understanding how anything that could
> > possibly make a project crash and burn could be "out of scope" for
> > XP, which is all about making projects work.
> 
> I'm a little late to this conversational party, but I'm intrigued by
> your statement.

You really shouldn't be intrigued that I have trouble understanding 
some things. I have trouble understanding almost everything. :)

> One of the big things I liked about XP on first encounter was that it
> _doesn't_ try to be everything. 

Agree. It only tries to be a list of things programmers and customers 
can do to improve their chances of shipping good software on time. At 
least, that's how I see it.

> There are lots of things that can make projects fail that we would
> probably agree are out of scope for XP: lack of adequate funding, poor
> HR practices, incompentent management, poor estimate of the market for
> a product, etc. 

I'd like to agree with you, but I'm puzzled by a couple things. For 
instance, if we are resigned to suffer from poor hiring practices, 
can we honestly say that we care about doing pair programming right ?

It seems to me that the ideal of pair programming implies that 
programmers have a say in whom they'll be pairing with. Maybe HR 
doesn't mind hiring coders who shower once a year, because people 
work out of cubicles; but coders who pair program will certainly
(Continue reading)

Permalink | Reply | 3 comments |
headers
jeffgrigg63132 | 1 Apr 2002 01:48
Favicon

RE: replace asserts with comments

> Around Sunday, March 31, 2002, 2:46:42 PM, C. Keith Ray wrote:
> > It's not lack of trust, it is executable documentation. The
> > asserts document what the allowed ranges of input are, and
> > the expected outputs or states, in a way that ALSO alerts
> > us when those assertions are violated.

--- Ron Jeffries <ronjeffries <at> a...> wrote:
> Why don't you replace the asserts with comments?
> 
> Ron Jeffries
> www.XProgramming.com
> It's easier to act your way into a new way of thinking
> than to think your way into a new way of acting.  --Millard Fuller

"Replace asserts with comments"???
This can't be the real Ron Jefferies!!!   It's an IMPOSTER!!!!

--  the real jeff

"I have a firm grip on reality. Now I can strangle it."

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

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

ad-free courtesy of objectmentor.com 

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

Permalink | Reply | 1 comment |
headers
C. Keith Ray | 1 Apr 2002 02:23
Picon

Re: Test Objectives (was: Re: Unit Test Challenge II)

on 2002.03.31 2:11 PM, Ron Jeffries at ronjeffries <at> acm.org wrote:

> Around Sunday, March 31, 2002, 2:46:42 PM, C. Keith Ray wrote:
[...]
>> It's not lack of trust, it is executable documentation. The asserts document
>> what the allowed ranges of input are, and the expected outputs or states, in
>> a way that ALSO alerts us when those assertions are violated.
> 
> Why don't you replace the asserts with comments?
> 
> Ron Jeffries
> www.XProgramming.com
> It's easier to act your way into a new way of thinking
> than to think your way into a new way of acting.  --Millard Fuller

  :-O     <-- mouth open, speechless.

----

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

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

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

ad-free courtesy of objectmentor.com 

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

Permalink | Reply | 86 comments |
headers
Charlie Poole | 1 Apr 2002 03:25
Favicon

RE: Ask the Customer

Laurent,

> > One of the big things I liked about XP on first encounter was that it
> > _doesn't_ try to be everything. 
> 
> Agree. It only tries to be a list of things programmers and customers 
> can do to improve their chances of shipping good software on time. At 
> least, that's how I see it.
> 
> > There are lots of things that can make projects fail that we would
> > probably agree are out of scope for XP: lack of adequate funding, poor
> > HR practices, incompentent management, poor estimate of the market for
> > a product, etc. 
> 
> I'd like to agree with you, but I'm puzzled by a couple things. For 
> instance, if we are resigned to suffer from poor hiring practices, 
> can we honestly say that we care about doing pair programming right ?

I'm not saying that we are resigned to such things. We shouldn't be.
But that doesn't mean XP has to give us the answers about how to
deal with it. Of course, even if XP doesn't give the answers, you
can still find them on this list. ;-)

If we need to negotiate with the HR folks and the CEO about hiring 
practices, we need some knowledge of hiring practices in general, 
employment law, management and possibly finance - not to mention how 
to negotiate. It would be silly to expect XP to teach us how to do
those things, and most people wouldn't.

> > This leads me to conclude that  the seriousness of the impact of some
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Apr 2002 03:27
Picon
Favicon
Gravatar

Re: replace asserts with comments

Around Sunday, March 31, 2002, 6:48:44 PM, jeffgrigg63132 wrote:

>> Around Sunday, March 31, 2002, 2:46:42 PM, C. Keith Ray wrote:
>> > It's not lack of trust, it is executable documentation. The
>> > asserts document what the allowed ranges of input are, and
>> > the expected outputs or states, in a way that ALSO alerts
>> > us when those assertions are violated.

> --- Ron Jeffries <ronjeffries <at> a...> wrote:
>> Why don't you replace the asserts with comments?
>> 
>> Ron Jeffries
>> www.XProgramming.com
>> It's easier to act your way into a new way of thinking
>> than to think your way into a new way of acting.  --Millard Fuller

> "Replace asserts with comments"???
> This can't be the real Ron Jefferies!!!   It's an IMPOSTER!!!!

Answer the question. It wasn't a recommendation, it was a question
intended to draw out whether it's really not lack of trust.

Why don't you replace the asserts with comments?

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

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

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Apr 2002 03:28
Picon
Favicon
Gravatar

Re: Test Objectives (was: Re: Unit Test Challenge II)

Around Sunday, March 31, 2002, 7:23:04 PM, C. Keith Ray wrote:

>> Why don't you replace the asserts with comments?
>> 
>> Ron Jeffries
>> www.XProgramming.com
>> It's easier to act your way into a new way of thinking
>> than to think your way into a new way of acting.  --Millard Fuller

>   :-O     <-- mouth open, speechless.

Things ending with "?" are questions. Things ending with "." are
statements. There's a difference. Isn't there?

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

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

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

ad-free courtesy of objectmentor.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 85 comments |
headers
Thomas Robbs | 1 Apr 2002 03:35
Picon
Favicon

Re: Test Objectives

I had to recently switch to digest mode just to keep
Yahoo's quota police happy, so I'm taking snippits
from various responses to my original post.  Forgive
the heaps that I left on the cutting room floor, but I
wanted to summarize my thoughts on all the posts.

Also, when I mention tester, developer, customer, or
any other role, please understand that I'm referring
to "hats" vs. unique individuals.

--- "Laurent Bossavit" <laurent <at> bossavit.com>

> "Testing" in this sense - traditional after-the-fact
QA testing, beta 
> testing, however it's called - seems to me to always
involve (at 
> least) two categories of verification.
>
> One is "expected outcomes"...[snip]
> The other is "abnormal outcomes" ... [snip]
>
> It seems to me that testing for abnormal outcomes is
a way of probing 
> the system's design, just as you describe. I have an
intuition - not 
> one that I can prove at the moment, though - that a
well-designed 
> system, such as one arising from test-driven design
and diligent 
> refactoring, will exhibit the property of responding
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Poole | 1 Apr 2002 03:38
Favicon

RE: Ask the Customer

Ron,

> I've been perhaps the primary source of the tight definition of XP,
> especially in the form "if you aren't doing x then you aren't doing
> XP". The folks above, among others, are taking a different approach to
> saying what XP is.

I hadn't noticed till you mentioned it. :-)

From descriptions of your own practices on the list, it has seemed
that you are pretty flexible in doing what you think is right - or
possible - even when it doesn't match XP practices exactly.

So in practical terms, what's the distinction between one who has
a "tight" definition of XP but is willing to compromise it when
called for and someone who does the same things but calls whatever
they do "XP?"

Not a position - just a question.

Charlie Poole
cpoole <at> pooleconsulting.com

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

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

ad-free courtesy of objectmentor.com 

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

Permalink | Reply | 2 comments |
headers
Laurent Bossavit | 1 Apr 2002 03:43

RE: Ask the Customer

> If we need to negotiate with the HR folks and the CEO about hiring 
> practices, we need some knowledge of hiring practices in general, 
> employment law, management and possibly finance - not to mention how 
> to negotiate. It would be silly to expect XP to teach us how to do
> those things, and most people wouldn't.

All right, I'm easy. If XPers come up and say that XP has taught them 
nothing about how to go about hiring their peers, then it should seem 
natural to me to say that hiring practices are out of scope for XP. 
What if XPers come up and share experiences to the contrary ?

XP has taught me plenty about how to negotiate, too. There are many 
things about that which are implicit in the Planning Game.

> > If we (I mean we XPers) thought we had a way of telling people about 
> > those things, such that they would somehow do the right things, don't 
> > you think we would have made it a part of XP without even stopping to 
> > think twice about whether it was "in scope" or not ?
> 
> What are the right things?

Not doing any of the wrong, harmful things would be a start. Maybe it 
is with management like it seems to be with design. :)

> This could just be an academic argument - which wouldn't bother either
> of us, I suppose :-) - but I don't think so. I think we need to know
> our bounds. 

Agree. But we might differ on exactly where these bounds are - at a 
given moment, since they certainly could be shifting, as well.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Laurent Bossavit | 1 Apr 2002 03:51

Re: Re: Test Objectives

> So, if I try and summarize those four paragraphs, I gather that on one
> hand you wouldn't let me off the hook for not finding the defect ("oh,
> we'll add a test for that"), but on the other you would accept the
> blame as the customer for not having stated that you wanted that
> scenario covered up front? ("doing our programs a disservice when we
> encourage them to become complex, defensive and bulletproof.")  Or am I
> missing something? 

What Bill Caputo said : the test-driven program won't crash, because 
most of its input checking will be done at well-defined boundaries 
where such checking is simple to do once and only once.

So, yes, as Customer it is my job to think of weird combinations of 
input data that I *still* want to be covered by the system; but it's 
your job as a programmer to write well-designed programs, and it 
seems to me that this will perforce imply a degree of robustness. 
Which is a lucky break for all involved. :)

-[Morendil]-
Reading this tagline will void its warranty.

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

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

ad-free courtesy of objectmentor.com 

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

Permalink | Reply | 0 comments |

Gmane