Perhaps what this means is that we all need to learn to be experts in
making choices, in particular, in making choices that are right for us.

It doesn't matter to me what brand of frozen green peas I am eating - it
may not important to me if I am eating peas or corn - it may not matter
to me if I am eating a veggie, or french fries.    So if I spend all the
time trying to figure out which I will eat, I am wasting my time and
energy.  Just picking one at random works.

I will have to track down the article and read it - it feels like the
problem isn't with having two many choices, but that people don't have a
good way of sorting through the choices they have.   

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Sent: Sunday, January 02, 2005 5:02 PM
To: [EMAIL PROTECTED]
Subject: [XP] Digest Number 4733



There are 19 messages in this issue.

Topics in this digest:

      1. Re: Tyranny of Flexible Scope?
           From: [EMAIL PROTECTED]
      2. Re: Workshop: Programming Intensive
           From: Keith Ray <[EMAIL PROTECTED]>
      3. Re: Asynchronous versus synchronous continuous integration
           From: Gary Feldman <[EMAIL PROTECTED]>
      4. Re: Tyranny of Flexible Scope?
           From: "Jason Yip" <[EMAIL PROTECTED]>
      5. Re: Asynchronous versus synchronous continuous integration
           From: Gary Feldman <[EMAIL PROTECTED]>
      6. Re: Asynchronous versus synchronous continuous integration
           From: Robert Watkins <[EMAIL PROTECTED]>
      7. Re: Asynchronous versus synchronous continuous integration
           From: Ron Jeffries <[EMAIL PROTECTED]>
      8. Re: Asynchronous versus synchronous continuous integration
           From: Robert Watkins <[EMAIL PROTECTED]>
      9. Re: Asynchronous versus synchronous continuous integration
           From: Steve Berczuk <[EMAIL PROTECTED]>
     10. Re: Asynchronous versus synchronous continuous integration
           From: Ron Jeffries <[EMAIL PROTECTED]>
     11. Re: Tyranny of Flexible Scope?
           From: "Paul McKerley" <[EMAIL PROTECTED]>
     12. Re: Asynchronous versus synchronous continuous integration
           From: Ron Jeffries <[EMAIL PROTECTED]>
     13. Re: Tyranny of Flexible Scope?
           From: William Wake <[EMAIL PROTECTED]>
     14. Re: Tyranny of Flexible Scope?
           From: Ron Jeffries <[EMAIL PROTECTED]>
     15. Re: Tyranny of Flexible Scope?
           From: Bernard Choi <[EMAIL PROTECTED]>
     16. Re: Tyranny of Flexible Scope?
           From: Ron Jeffries <[EMAIL PROTECTED]>
     17. Re: Tyranny of Flexible Scope?
           From: William Wake <[EMAIL PROTECTED]>
     18. RE: Tyranny of Flexible Scope?
           From: "Kay Pentecost" <[EMAIL PROTECTED]>
     19. Re: New Article - BowlingForSmalltalkV - a small procedural
example
           From: "Jeff Grigg" <[EMAIL PROTECTED]>


________________________________________________________________________
________________________________________________________________________

Message: 1         
   Date: Sat, 1 Jan 2005 20:05:08 EST
   From: [EMAIL PROTECTED]
Subject: Re: Tyranny of Flexible Scope?

 
 
This is fascinating... In 1985 my wife Deanna and I visited East Berlin.

After visiting a supermarket, where we saw many clear plastic bags of
frozen  
identical but unnamed green things as constituting the frozen vegetable
section,  
we walked outside and found, on the corner of the building, a sign
behind a  
glass case, reading, "Wer hat die Wahl, hat auch die Qual." Translated:
Who 
has  a choice, has also the torment/agony. (In German there is a phrase,
"Die 
Quahl  der Wal" meaning, the agony/torment/torture of choice) .
 
It seemed at the time a piece of propaganda reminding people they really

didn't want to be tortured by having to make choices (eg, between
various green  
frozen things).
 
And yet I don't know many people who'd switch places.... It does make me

wonder about his research....  Alistair
 
<<I recently read a April 2004 Scientific American article called  The
Tyranny of Choice by Barry Schwartz.  I first learned of his  research
from a reference in Authentic Happiness by Martin  Seligman.

In a nutshell, not having choice leads to disappointment but  having
many choices and "choosing wrong" leads to regret.  Apparently  regret
is a greater detriment to happiness than  disappointment.

Lessons from the article are:
- Choose when to  choose
- Learn to accept "good enough"
- Don't worry about what you're  missing
- Control expectations

So, triggered by the talk about  Optional Scope contracts, I'm wondering
if I or others have observed the  "tyranny of choice" phenomenon
manifested as resistance to introducing a more  flexible scope approach.

Don't know where I'm going with this yet...  probably need to do more
observations and reflect a bit more  first...>>
 
 




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



________________________________________________________________________
________________________________________________________________________

Message: 2         
   Date: Sat, 1 Jan 2005 19:26:36 -0800
   From: Keith Ray <[EMAIL PROTECTED]>
Subject: Re: Workshop: Programming Intensive

Interesting... I was thinking, if I had some free time available, of 
trying to TTD up a poker-bot environment... people could try encoding 
their poker strategies into subclass of PokerBot, and the environment 
instantiates instances of them, running hundreds of poker games a 
minute to determine which strategies really work.

On Dec 30, 2004, at 2:26 PM, Kent Beck wrote:

>
> I will be hosting a four-day workshop January 31-February 3 here in
> southern
> Oregon. The goal of the workshop is to help participants revitalize 
> their
> interest in programming by working on games of their choice and
helping
> other participants with their projects. Please see
> http://www.threeriversinstitute.org/Programming%20Intensive.htm for 
> more
> information.
>
> Kent Beck
> Three Rivers Consulting, Inc.
>
>
>
> To Post a message, send it to:   [EMAIL PROTECTED]
>
> To Unsubscribe, send a blank message to:
> [EMAIL PROTECTED]
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
--
C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>



________________________________________________________________________
________________________________________________________________________

Message: 3         
   Date: Sat, 01 Jan 2005 22:30:55 -0500
   From: Gary Feldman <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

Robert Watkins wrote:

> I would also posit that certain QA practices, such as determining test
> coverage levels, take more time than a developer wants to spend, and
don't 
> make much sense for a developer to run anyway.

Why do you say that?  I recently deployed Emma (Java coverage) in our
build file for one component, making it both fast and easy for
developers to get coverage data.  It's trivial for the developers to
run, and it creates a good target for them when doing after-the-fact
unit testing.  (This isn't an XP or TDD shop - yet.)  

In traditional development, most developers find it difficult to unit
test their own code, or to know when their tests are good enough.  It
becomes frustrating for them because they're not used to thinking that
way, and can't predict when they'll be done because they don't have a
good definition of "done" for unit tests on existing code.  Making it
easy for developers to use coverage tools solves these problems, by
giving them a much more concrete definition of being done.  The
developers are happier and the unit tests are likely better than they
would have been had they been left to write them with no coverage tools.

Gary



________________________________________________________________________
________________________________________________________________________

Message: 4         
   Date: Sun, 02 Jan 2005 04:14:05 -0000
   From: "Jason Yip" <[EMAIL PROTECTED]>
Subject: Re: Tyranny of Flexible Scope?


Hi Alistair,

I think the distinction is that no choice is bad, some choice is good,
but too much choice becomes bad again.

If all I have to choose from is unnamed green things, I can blame the
East German government.  External factor.

If I get to choose from 10 different versions of chopped broccoli, that
might also be available at different prices at 10 different stores...
Well, if the selected broccoli ends up tasting like cardboard and I also
learn that I could have gotten it for half price at another store, I
might just blame myself.  Internal factor.

--- In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
>  
>  
> This is fascinating... In 1985 my wife Deanna and I visited East
Berlin.  
> After visiting a supermarket, where we saw many clear plastic bags
of frozen  
> identical but unnamed green things as constituting the frozen
vegetable section,  
> we walked outside and found, on the corner of the building, a sign
behind a  
> glass case, reading, "Wer hat die Wahl, hat auch die Qual."
Translated: Who 
> has  a choice, has also the torment/agony. (In German there is a
phrase, "Die 
> Quahl  der Wal" meaning, the agony/torment/torture of choice) .
>  
> It seemed at the time a piece of propaganda reminding people they
really  
> didn't want to be tortured by having to make choices (eg, between
various green  
> frozen things).
>  
> And yet I don't know many people who'd switch places.... It does
make me  
> wonder about his research....  Alistair






________________________________________________________________________
________________________________________________________________________

Message: 5         
   Date: Sat, 01 Jan 2005 23:28:05 -0500
   From: Gary Feldman <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

Kent Beck wrote:

> That seems inefficient to me. It's worth ten
> minutes of waiting to avoid eleven minutes of task switching (YMMV).

For me, waiting _is_ a task switch.  Robert Watkins mentioned "actively
reflecting on what you've done," but that's a context switch, too.  It's
a switch from problem solving mode to analysis mode.  It's also a
difficult transition to make at that point; I find it much easier to
meditate on a new problem than to meditate on something that I'm hoping
is finished.  

I can see I'm going to have to get my hands on the new edition.  In the
meantime, I think that YMMV is very significant.

Gary





________________________________________________________________________
________________________________________________________________________

Message: 6         
   Date: Sun, 02 Jan 2005 19:37:43 +1000
   From: Robert Watkins <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

Gary Feldman wrote:
> Why do you say that?  I recently deployed Emma (Java coverage) in our 
> build file for one component, making it both fast and easy for 
> developers to get coverage data.  It's trivial for the developers to 
> run, and it creates a good target for them when doing after-the-fact 
> unit testing.  (This isn't an XP or TDD shop - yet.)

I don't know about Emma, but the one that I use (Clover) can't be used 
readily in conjunction with a production-like environment. Having to
blow 
away and rebuild just because you want to deploy an application gets
really 
annoying (this, BTW, is exactly what the CruiseControl build target
does).

-- 
                "Software is too expensive to build cheaply"
Robert Watkins         http://twasink.net/          [EMAIL PROTECTED]


________________________________________________________________________
________________________________________________________________________

Message: 7         
   Date: Sun, 2 Jan 2005 07:01:28 -0500
   From: Ron Jeffries <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

On Saturday, January 1, 2005, at 5:06:23 PM, Robert Watkins wrote:

> Ron Jeffries wrote:
>> Use of "many resources" will not make the tests better.
>> 
>> Running them asynchronously is done because they take a long time. 
>> The fact that it takes a long time to know if you've done good work 
>> is the bug. Fix it.

> I would posit that certain tests, by their very nature, have to take a

> long time. Performance profiling and endurance tests come to mind. 
> Also, acceptance tests (which typically use the system in a deployed 
> state, not an abstracted one like unit tests) take longer to run, 
> particularly if a database is involved. Even if you stub out part of 
> the infrastructure for the acceptanace tests, you need to have at 
> least some end-to-end tests to ensure that everything does hang 
> together.

Yes, well, that's the problem. To me, "posit" means "assume" or
"accept". That means it's OK for certain tests to be long. That leads to
acceptance of the fact that tests take a long time. That leads to slower
feedback.

I don't like slow feedback. Therefore, I do not "posit" that the nature
of things is that tests are slow. I posit that a slow test is a bad test
until proven otherwise.

Not surprisingly, approaching slow tests with this attitude leads to
tests that run faster. Not all of them, of course, because some of them
are innocent even if assumed guilty.

> I would also posit that certain QA practices, such as determining test

> coverage levels, take more time than a developer wants to spend, and 
> don't make much sense for a developer to run anyway.

Again, that's one way to be certain that I'll never have a coverage tool
that helps me when I'm coding. I think we can do better.

If I'm doing TDD, working in small increments, I'm perhaps only
interested in incremental coverage, on the code I'm working on. A decent
tool could tell me that. Imagine if my IDE highlighted all the code not
yet executed by my tests. That would be very valuable.

> A layered build approach (which CruiseControl supports "out of the
> box") makes a lot of sense in such a scenario. Does this describe 
> every team? No.

It would not surprise me to find that every real team has tests that
they don't run all the time. But my reaction would not be "let's never
commit the code until a thousand years of testing has elapsed." It would
be "let's find a way to do enough testing in minutes, then use the
thousand years to find out whether we've made a mistake."

If more than one pair release has taken place, we really don't know what
caused the problem when the thousand year tests fail. That's not good.
If our thoughts have moved on, that's not good.

Therefore -- in my opinion -- the vector should point in the direction
of getting all the necessary info instantly, not in the direction of
tolerating and accommodating slow feedback.

> Note that reducing build times is still important when using a build 
> server. The build status is feedback information; you do want it as 
> soon as possible.

Yes, exactly.

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? --  E M Forster




________________________________________________________________________
________________________________________________________________________

Message: 8         
   Date: Sun, 02 Jan 2005 23:41:11 +1000
   From: Robert Watkins <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

Ron Jeffries wrote:
> If more than one pair release has taken place, we really don't know 
> what caused the problem when the thousand year tests fail. That's not 
> good. If our thoughts have moved on, that's not good.
> 
> Therefore -- in my opinion -- the vector should point in the direction

> of getting all the necessary info instantly, not in the direction of 
> tolerating and accommodating slow feedback.

Shouldn't it point towards effectiveness? Important but non urgent
feedback 
can certainly be delayed. It is this sort of feedback that the
asynchronous 
builds are designed to give (as well as being a safety net for the
normal 
developer builds).

-- 
                "Software is too expensive to build cheaply"
Robert Watkins         http://twasink.net/          [EMAIL PROTECTED]


________________________________________________________________________
________________________________________________________________________

Message: 9         
   Date: Sun, 2 Jan 2005 10:12:54 -0500
   From: Steve Berczuk <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

On Sun, 02 Jan 2005 23:41:11 +1000, Robert Watkins <[EMAIL PROTECTED]>
wrote:
> 
> Ron Jeffries wrote:
> > Therefore -- in my opinion -- the vector should point in the 
> > direction of getting all the necessary info instantly, not in the 
> > direction of tolerating and accommodating slow feedback.
> 
> Shouldn't it point towards effectiveness? Important but non urgent 
> feedback can certainly be delayed. It is this sort of feedback that 
> the asynchronous builds are designed to give (as well as being a 
> safety net for the normal developer builds).

This is the point that I was trying to make: It makes sense to think in
terms of horizons...  very short term: immediate feedback (ie, syntax
error highlighting, unit tests for the class you are changing, etc)
short term: Quick feedback, fairly good confidence  medium term: slower
feedback, very good confidence that everything works.

Having said that, if you have an application where you can run ALL of
your unit tests, and all of your integration level tests in a short
time, there is no reason not to run all the tests pre-checkin,  and post
checkin while waiting for the feedback.

One thing that bothers/confuses me about this discussion: we seem to be
mixing up two concepts:
  -A- offline tests with feedback for convenience (resources, time, as a
safety net)
  -2-  offline tests because no one runs tests.

for (A), we can argue about what is best, but as long as the tests run
and people care and react, the result is good.

for (2), you have bigger problems, and automating the tests is a
band-aid.

-steve

-- 
Steve Berczuk  | [EMAIL PROTECTED] | http://www.berczuk.com
 SCM Patterns: Effective Teamwork, Practical Integration
     www.scmpatterns.com


________________________________________________________________________
________________________________________________________________________

Message: 10        
   Date: Sun, 2 Jan 2005 10:34:04 -0500
   From: Ron Jeffries <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

On Sunday, January 2, 2005, at 8:41:11 AM, Robert Watkins wrote:

> Ron Jeffries wrote:
>> If more than one pair release has taken place, we really don't know 
>> what caused the problem when the thousand year tests fail. That's not

>> good. If our thoughts have moved on, that's not good.
>> 
>> Therefore -- in my opinion -- the vector should point in the 
>> direction of getting all the necessary info instantly, not in the 
>> direction of tolerating and accommodating slow feedback.

> Shouldn't it point towards effectiveness? Important but non urgent 
> feedback can certainly be delayed. It is this sort of feedback that 
> the asynchronous builds are designed to give (as well as being a 
> safety net for the normal developer builds).

"Be effective." What kind of advice is that?

Practice vectors can't point towards effectiveness: there's no measure
of that. Practice vectors say "test more", or "integrate more often", or
"sit together".

The practice vectors are there to remind us that what we're used to ....
what we "posit" ... isn't necessarily the way things ought to be.

Ron Jeffries
www.XProgramming.com
Do I contradict myself? Very well then I contradict myself.
(I am large, I contain multitudes.) --Walt Whitman




________________________________________________________________________
________________________________________________________________________

Message: 11        
   Date: Sun, 02 Jan 2005 15:15:49 -0000
   From: "Paul McKerley" <[EMAIL PROTECTED]>
Subject: Re: Tyranny of Flexible Scope?



> I think the distinction is that no choice is bad, some choice is
good,
> but too much choice becomes bad again.
> 
> If all I have to choose from is unnamed green things, I can blame
the
> East German government.  External factor.
> 
> If I get to choose from 10 different versions of chopped broccoli, 
> that might also be available at different prices at 10 different 
> stores...  Well, if the selected broccoli ends up tasting like 
> cardboard and I also learn that I could have gotten it for half
price
> at another store, I might just blame myself.  Internal factor.
> 

Hi Jason:

I can think of a couple considerations: as long as the choices aren't
fatal, then the bad feeling resulting from a bad choice is part of the
learning process. If you choose the wrong frozen broccoli in a market
society, you can choose another variety the next day. Keep trying and
eventually you'll feel good. In East Germany the bad feelings were
eternal. 

The other consideration is that in many cases decisions still need to be
made--the question is, who shall make them? In market societies the
ideal is that the person most affected by a decision is the one who
makes it and is responsible for the outcome. In planned economies the
person making the decision bears none of the consequences. For example,
it's likely that the senior East German bureaucrats responsible for
vegetable production and distribution enjoyed a variety fresh fruits and
vegetables every day, regardless of the fact that their decisions
deprived most of their countrymen of the same. 

I'm just new to XP (just finished Extreme Programming
Explained over Christmas) so I'm no expert on the practices or
principles, but it seems to me that there are analogies here to XP--one
of the values is that people are responsible for their decisions, good
or bad.

Paul








________________________________________________________________________
________________________________________________________________________

Message: 12        
   Date: Sun, 2 Jan 2005 13:18:17 -0500
   From: Ron Jeffries <[EMAIL PROTECTED]>
Subject: Re: Asynchronous versus synchronous continuous integration

Around Sunday, January 2, 2005, 10:34:04 AM, Ron Jeffries wrote:

> "Be effective." What kind of advice is that?

Does that come across as too harsh? I don't mean it to be. I do mean to
say, though, that the practices, as I envision them, are behavioral
dictates that -- if practiced -- will teach us things we likely didn't
know.

So "get all the tests run and still keep your code release to ten
minutes" might be such a thing: in trying to do it, we'll learn
something.

One of the things we might learn would be when and when not to live
within this rule, and I frankly expect that most of us would learn
something different from what we'd have predicted before trying the ten
minute rule.

Another thing we might learn would be a lot of ways to get good tests
that run fast. Again, we might not likely have learned that had we not
followed the vector.

We would be learning to be more effective ... but we would be learning a
new level of effectiveness, and new value to effectiveness, that would
have never come about had we just said "be effective".

That's what I'm talkin' about.

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? --  E M Forster




________________________________________________________________________
________________________________________________________________________

Message: 13        
   Date: Sun, 2 Jan 2005 13:32:48 -0500
   From: William Wake <[EMAIL PROTECTED]>
Subject: Re: Tyranny of Flexible Scope?

On Sun, 02 Jan 2005 15:15:49 -0000, Paul McKerley <[EMAIL PROTECTED]>
wrote:
> I can think of a couple considerations: as long as the choices aren't 
> fatal, then the bad feeling resulting from a bad choice is part of the

> learning process. If you choose the wrong frozen broccoli in a market 
> society, you can choose another variety the next day. Keep trying and 
> eventually you'll feel good.

But the thesis is that it isn't true. Broccoli may not be the best
demonstration of this. Think more like the computer market - suppose you
really need a new computer and agonize over the choices. Then next month
feature xyz comes out and you have this feeling like you're missing
something. (The article that started this identified two sort of
psychological poles, depending whether you felt this regret or
not.)

Don't forget there's a cost to all the choice too. By the time I've
tried all the 10 current choices, there are a couple more out there. And
don't forget the 7 kinds of okra, etc. I'm paying effort to keep track
of all these differences, but they don't really add up to all that much.
(I'm sure it was easier to shop for cars in Henry Ford's day - I'll take
one model T, black; cars are certainly better now, but buying a new car
is more work too:)

My sister lived in Thailand for a couple years; she had a huge
adjustment coming back to the states and feeling overwhelmed just
looking at all the cereal choices in the grocery store.

> The other consideration is that in many cases decisions still need to 
> be made--the question is, who shall make them? In market societies the

> ideal is that the person most affected by a decision is the one who 
> makes it and is responsible for the outcome.

That's the problem too, isn't it? Each supplier wants you to make one
more decision. This creates an explosion of choices. And like most
everybody else, I'm out there trying to create more choices for people
too.

-- 
   Bill Wake  [EMAIL PROTECTED]  www.xp123.com


________________________________________________________________________
________________________________________________________________________

Message: 14        
   Date: Sun, 2 Jan 2005 13:48:24 -0500
   From: Ron Jeffries <[EMAIL PROTECTED]>
Subject: Re: Tyranny of Flexible Scope?

On Sunday, January 2, 2005, at 1:32:48 PM, William Wake wrote:

>> The other consideration is that in many cases decisions still need to

>> be made--the question is, who shall make them? In market societies 
>> the ideal is that the person most affected by a decision is the one 
>> who makes it and is responsible for the outcome.

> That's the problem too, isn't it? Each supplier wants you to make one 
> more decision. This creates an explosion of choices. And like most 
> everybody else, I'm out there trying to create more choices for people

> too.

I guess this is a deep question. Yet, to me, it's not. I don't like not
having choices. I don't like people telling me what I can have and can't
have, what I must do and what I may not do.

Now that may seem odd, coming from a guy whose whole position on XP is
"Do this, and someday you'll understand why." But it's actually quite
consistent.

I don't want anyone forced to do the practices of XP, or anything else.
I want them to /choose/ to do the practices, to /choose/ to learn
whatever they teach.

When I go to taiji class, I don't expect to tell the instructor how to
teach me. If he teaches me in a way that I don't like, I'll get another
instructor. And I'll even tell him "when you did this, this happened to
me, but when you did that ...". But when it comes down to it, in this
class that I chose, he's the master ... not in the sense of I'm the
slave, but in the sense of I'm the student. His job is to tell me what
to do next, choosing in such a way as to cause me to learn something.

I choose to learn, by trying things. I then learn to choose among a
wider range of choices and, among them, to choose better.

I choose choice.

Ron Jeffries
www.XProgramming.com
It is better to have less thunder in the mouth
and more lightning in the hand.  -- Apache proverb




________________________________________________________________________
________________________________________________________________________

Message: 15        
   Date: Mon, 03 Jan 2005 02:59:08 +0800
   From: Bernard Choi <[EMAIL PROTECTED]>
Subject: Re: Tyranny of Flexible Scope?


>>The other consideration is that in many cases decisions still need to 
>>be made--the question is, who shall make them? In market societies the

>>ideal is that the person most affected by a decision is the one who 
>>makes it and is responsible for the outcome.
>>    
>>
>
>That's the problem too, isn't it? Each supplier wants you to make one 
>more decision. This creates an explosion of choices. And like most 
>everybody else, I'm out there trying to create more choices for people 
>too.
>  
>
Not to mention that the person making the choice may not be the one most

qualified ? My son may be most affected by my choice of Broccoli or 
Chocolate for dinner, but I still make the call.


________________________________________________________________________
________________________________________________________________________

Message: 16        
   Date: Sun, 2 Jan 2005 14:02:54 -0500
   From: Ron Jeffries <[EMAIL PROTECTED]>
Subject: Re: Tyranny of Flexible Scope?

On Sunday, January 2, 2005, at 1:59:08 PM, Bernard Choi wrote:

>>That's the problem too, isn't it? Each supplier wants you to make one 
>>more decision. This creates an explosion of choices. And like most 
>>everybody else, I'm out there trying to create more choices for people

>>too.
>>  
>>
> Not to mention that the person making the choice may not be the one 
> most qualified ? My son may be most affected by my choice of Broccoli 
> or Chocolate for dinner, but I still make the call.

If your son is 6, that's one thing. If he's 36, that's quite another.

Ron Jeffries
www.XProgramming.com
You are to act in the light of experience as guided by intelligence.  
-- Nero Wolfe




________________________________________________________________________
________________________________________________________________________

Message: 17        
   Date: Sun, 2 Jan 2005 14:27:01 -0500
   From: William Wake <[EMAIL PROTECTED]>
Subject: Re: Tyranny of Flexible Scope?

On Sun, 2 Jan 2005 13:48:24 -0500, Ron Jeffries
<[EMAIL PROTECTED]> wrote:
> 
> On Sunday, January 2, 2005, at 1:32:48 PM, William Wake wrote: I don't

> like not having choices. I don't like people telling me what I can 
> have and can't have, what I must do and what I may not do.

I relate to that too. But I can certainly believe there can be too many
choices. (Or worse, too many choices without a 'real'
difference.) The SciAm article's claim was, "yes, you can have too many
choices, and some people are there now."

I remember the ads for toys, "limited only by your own imagination." I
always thought, "Ooh - too bad." :)

-- 
   Bill Wake  [EMAIL PROTECTED]  www.xp123.com


________________________________________________________________________
________________________________________________________________________

Message: 18        
   Date: Sun, 2 Jan 2005 14:53:01 -0500
   From: "Kay Pentecost" <[EMAIL PROTECTED]>
Subject: RE: Tyranny of Flexible Scope?

Hi, Everybody,

Interesting thing about having a lot of choices.  

It seems to me that we always want more choices for ourselves... we can
deal with the consequences of making a bad decision if we still have the
choice to correct it.

And yet, many of us want to limit the choices other people have.  

For example, we create a software program that locks people into doing a
task a particular way.  Or we modify an operating system command... say
aliasing "ls" as "ls -l" because we think the user won't want to/be able
to? learn the "right" way.

Do we project our fears onto others?  I wonder if we think, yeah, I can
deal with lots of choices, but he/she/it will be confused?

Kay 





________________________________________________________________________
________________________________________________________________________

Message: 19        
   Date: Sun, 02 Jan 2005 21:29:07 -0000
   From: "Jeff Grigg" <[EMAIL PROTECTED]>
Subject: Re: New Article - BowlingForSmalltalkV - a small procedural
example


--- "aacockburn" <[EMAIL PROTECTED]> wrote:
> >>     open := roll1 + roll2 < 10.
> >>     spare := (roll1 < 10)   and:  (roll1 + roll2 = 10).
> >>     strike := roll1 = 10.

> --- JeffGrigg wrote:
> << Have you considered reversing the order and using not?
>    I think that reversing the order and using 'not' would
>    make it (at least more) clear that only one could be
>    set, and always one will be set.) >>

--- "aacockburn" <[EMAIL PROTECTED]> wrote:
> I have no trouble reversing the order to: 
>      strike := roll1 = 10.
>      spare := (roll1 < 10)   and:  (roll1 + roll2 = 10).
>      open := roll1 + roll2 < 10.
> but it should be clear somehow that they are mutually exclusive --- 
> two of them can't possibly be set.

Now I just have to figure out how to refactor my posts, so that they 
will be more clear!  ;->

What I had in mind was to reverse the order /and then use each 
boolean in the following expressions./  Like this:

  strike := roll1 = 10.
  spare  := (strike not) and: (roll1 + roll2 = 10).
  open   := (strike not) and: (spare not).

I get here by saying, "roll1 < 10" means "not a strike."  The 
expression for "open" is more complex now, but I think it does make 
it more clear that everything not a strike or spare is an "open."





________________________________________________________________________
________________________________________________________________________


To Post a message, send it to:   [EMAIL PROTECTED]

To Unsubscribe, send a blank message to:
[EMAIL PROTECTED]

ad-free courtesy of objectmentor.com
------------------------------------------------------------------------
Yahoo! Groups Links



 
------------------------------------------------------------------------








To Post a message, send it to:   [EMAIL PROTECTED]

To Unsubscribe, send a blank message to: [EMAIL PROTECTED]

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

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



Reply via email to