Loading ...
Sorry, an error occurred while loading the content.

Flexible scope

Expand Messages
  • Carl Schweppe
    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
    Message 1 of 1 , Jan 2, 2005
    • 0 Attachment
      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: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com]
      Sent: Sunday, January 02, 2005 5:02 PM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] Digest Number 4733



      There are 19 messages in this issue.

      Topics in this digest:

      1. Re: Tyranny of Flexible Scope?
      From: acockburn@...
      2. Re: Workshop: Programming Intensive
      From: Keith Ray <keithray@...>
      3. Re: Asynchronous versus synchronous continuous integration
      From: Gary Feldman <g1list_1a@...>
      4. Re: Tyranny of Flexible Scope?
      From: "Jason Yip" <j.c.yip@...>
      5. Re: Asynchronous versus synchronous continuous integration
      From: Gary Feldman <g1list_1a@...>
      6. Re: Asynchronous versus synchronous continuous integration
      From: Robert Watkins <yahoo@...>
      7. Re: Asynchronous versus synchronous continuous integration
      From: Ron Jeffries <ronjeffries@...>
      8. Re: Asynchronous versus synchronous continuous integration
      From: Robert Watkins <yahoo@...>
      9. Re: Asynchronous versus synchronous continuous integration
      From: Steve Berczuk <steve.berczuk@...>
      10. Re: Asynchronous versus synchronous continuous integration
      From: Ron Jeffries <ronjeffries@...>
      11. Re: Tyranny of Flexible Scope?
      From: "Paul McKerley" <mckerley@...>
      12. Re: Asynchronous versus synchronous continuous integration
      From: Ron Jeffries <ronjeffries@...>
      13. Re: Tyranny of Flexible Scope?
      From: William Wake <william.wake@...>
      14. Re: Tyranny of Flexible Scope?
      From: Ron Jeffries <ronjeffries@...>
      15. Re: Tyranny of Flexible Scope?
      From: Bernard Choi <bchoi@...>
      16. Re: Tyranny of Flexible Scope?
      From: Ron Jeffries <ronjeffries@...>
      17. Re: Tyranny of Flexible Scope?
      From: William Wake <william.wake@...>
      18. RE: Tyranny of Flexible Scope?
      From: "Kay Pentecost" <tranzpupy@...>
      19. Re: New Article - BowlingForSmalltalkV - a small procedural
      example
      From: "Jeff Grigg" <jeffgrigg@...>


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 1
      Date: Sat, 1 Jan 2005 20:05:08 EST
      From: acockburn@...
      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 <keithray@...>
      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: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > 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 <g1list_1a@...>
      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" <j.c.yip@...>
      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 extremeprogramming@yahoogroups.com, acockburn@a... 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 <g1list_1a@...>
      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 <yahoo@...>
      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/ robertdw@...


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 7
      Date: Sun, 2 Jan 2005 07:01:28 -0500
      From: Ron Jeffries <ronjeffries@...>
      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 <yahoo@...>
      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/ robertdw@...


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 9
      Date: Sun, 2 Jan 2005 10:12:54 -0500
      From: Steve Berczuk <steve.berczuk@...>
      Subject: Re: Asynchronous versus synchronous continuous integration

      On Sun, 02 Jan 2005 23:41:11 +1000, Robert Watkins <yahoo@...>
      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 | steve@... | 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 <ronjeffries@...>
      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" <mckerley@...>
      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 <ronjeffries@...>
      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 <william.wake@...>
      Subject: Re: Tyranny of Flexible Scope?

      On Sun, 02 Jan 2005 15:15:49 -0000, Paul McKerley <mckerley@...>
      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 William.Wake@... www.xp123.com


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 14
      Date: Sun, 2 Jan 2005 13:48:24 -0500
      From: Ron Jeffries <ronjeffries@...>
      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 <bchoi@...>
      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 <ronjeffries@...>
      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 <william.wake@...>
      Subject: Re: Tyranny of Flexible Scope?

      On Sun, 2 Jan 2005 13:48:24 -0500, Ron Jeffries
      <ronjeffries@...> 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 William.Wake@... www.xp123.com


      ________________________________________________________________________
      ________________________________________________________________________

      Message: 18
      Date: Sun, 2 Jan 2005 14:53:01 -0500
      From: "Kay Pentecost" <tranzpupy@...>
      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" <jeffgrigg@...>
      Subject: Re: New Article - BowlingForSmalltalkV - a small procedural
      example


      --- "aacockburn" <acockburn@a...> 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" <acockburn@a...> 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: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

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




      ------------------------------------------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.