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

[extremeprogramming] Re: You Aren't Gonna Need It Again

Expand Messages
  • Dave Thomas
    The following message is a courtesy copy of an article that has been posted to comp.object,comp.software-eng as well. ... Sorry, I was being obtuse. I keep
    Message 1 of 5 , Jan 3, 2000
      The following message is a courtesy copy of an article
      that has been posted to comp.object,comp.software-eng as well.

      Patrick Logan <patrick@...> writes:

      > In comp.object Dave Thomas <Dave@...> wrote:
      >
      > : Does XP recommend that developers read ad study stuff they're not
      > : currently working on, or do they wait until they have a particular
      > : need, and then find the most focused book available?
      >
      > I don't see where XP says anything about skill development outside of
      > the specific project. XP is a project management technique. Do any
      > other approaches to developing software mention these concerns? Is
      > there some reason they should? Or does that concern get addressed
      > elsewhere?

      Sorry, I was being obtuse. I keep coming back to the concept that
      JustInTime design and coding seems to encourage developers to work
      only up the end-of-the-day horizon. SeeingFurther has always been
      important to me, and I'm struggling mightily with the idea of giving
      it up. So, I was using the patently ridiculous idea of not bothering
      to read or study until you have a concrete requirement to further
      illustrate problems I feel with a jit approach.

      However, I'm really not speaking from a position of authority--I've
      not yet experienced a strict XP regime. Who knows, I may be happy to
      fling my foresight to the four winds?

      Dave


      --
      Thomas Consulting.
      Innovative and successful developments with Unix, Java, C, and C++.

      Now in bookstores:
      The Pragmatic Programmer. www.pragmaticprogrammer.com/ppbook/
    • Kent Beck
      Who knows, I may be happy to fling my foresight to the four winds? Trade it, rather, for greater focus, less stress, simpler designs, and faster development.
      Message 2 of 5 , Jan 3, 2000
        "Who knows, I may be happy to fling my foresight to the four winds?"

        Trade it, rather, for greater focus, less stress, simpler designs, and
        faster development. That's what I did about five years ago, trying to
        emulate what Ward does naturally.

        Just because you don't guess about tomorrow's requirements doesn't mean that
        experience is any less important. The experienced programmer can see
        problems and solutions much sooner than a newbie. The experienced extreme
        programmer simply leaves tomorrow problems until tomorrow.

        For example, I know 10-12 tricks to implementing multi-currency
        calculations. No one system has ever needed more than half of them. However,
        I have absolute confidence that when the time comes I will see the need for
        a trick and I will know how to retrofit it. If in the meantime I discover a
        new trick, I won't have a bunch of might-be-useful stuff getting in the way.

        That said, giving up my own need to "guess and be right" about design was
        personally painful. Now I'm happy that I made the switch. You'll have to
        decide for yourself whether the pain might be worth it. I suggest you
        shorten your design horizon a little at a time, or try a little project with
        completely evolutionary design.

        Kent
      • Ed Falis
        Kent, These are encouraging words for us old dogs. This particular aspect of things is a tough one to deal with on a personal level - I m in the throes of it
        Message 3 of 5 , Jan 4, 2000
          Kent,

          These are encouraging words for us old dogs. This particular aspect of
          things is a tough one to deal with on a personal level - I'm in the throes
          of it myself. Thanks.

          - Ed

          ----- Original Message -----
          >From: "Kent Beck" <kentbeck@...>
          To: <extremeprogramming@egroups.com>
          Sent: Tuesday, January 04, 2000 1:11 AM
          Subject: [extremeprogramming] Re: You Aren't Gonna Need It Again


          > "Who knows, I may be happy to fling my foresight to the four winds?"
          >
          > Trade it, rather, for greater focus, less stress, simpler designs, and
          > faster development. That's what I did about five years ago, trying to
          > emulate what Ward does naturally.
          >
          > Just because you don't guess about tomorrow's requirements doesn't mean
          that
          > experience is any less important. The experienced programmer can see
          > problems and solutions much sooner than a newbie. The experienced extreme
          > programmer simply leaves tomorrow problems until tomorrow.
          >
          > For example, I know 10-12 tricks to implementing multi-currency
          > calculations. No one system has ever needed more than half of them.
          However,
          > I have absolute confidence that when the time comes I will see the need
          for
          > a trick and I will know how to retrofit it. If in the meantime I discover
          a
          > new trick, I won't have a bunch of might-be-useful stuff getting in the
          way.
          >
          > That said, giving up my own need to "guess and be right" about design was
          > personally painful. Now I'm happy that I made the switch. You'll have to
          > decide for yourself whether the pain might be worth it. I suggest you
          > shorten your design horizon a little at a time, or try a little project
          with
          > completely evolutionary design.
          >
          > Kent
          >
          >
          >
          > ------------------------------------------------------------------------
          > To Post a message, send it to: extremeprogramming@...
          > To Unsubscribe, send a blank message to:
          extremeprogramming-unsubscribe@...
          >
          > ------------------------------------------------------------------------
          > Want to send money instantly to anyone, anywhere, anytime?
          > You can today at X.com - and we'll give you $20 to try it! Sign
          > up today at X.com. It's quick, free, & there's no obligation!
          > http://click.egroups.com/1/332/0/_/263270/_/946966421
          >
          > -- Talk to your group with your own voice!
          > -- http://www.egroups.com/VoiceChatPage?listName=extremeprogramming&m=1
          >
          >
          >
        • Phlip
          ... that ... should ... design ... I have three big functions, each showing the same control flow shape. My employer bio-peripheral tells me to add Feature X
          Message 4 of 5 , Jan 8, 2000
            Ronald E Jeffries wrote:

            > The YAGNI rule means: when you are working on a task and you get
            that
            > temptation to generalize, thinking "We're gonna need ...", you
            should
            > resist that temptation, stay on task, and trust your quality of
            design
            > and implementation to make the change easy enough if and when it's
            > really needed.

            I have three big functions, each showing the same control flow
            shape.

            My employer bio-peripheral tells me to add Feature X to all three
            functions.

            OnceAndOnlyOnce sez I should start by expressing the control flow of
            all three functions into one, using the Template Method DP. Then I
            write Feature X once, in the control flow function that dispatches
            to the virtual hook functions.

            Because OnceAndOnlyOnce sez I need it, YAGNI does not apply. The
            future need I would have resisted coddling was that other similar
            features would need the same control flow, and need Feature X. But
            without this instance of OAOO I would never have applied a pattern
            that also predicts future expansions. Adding new features now will
            not mean "brute-force code the new feature, and tack a copy of
            Feature X onto it." It will now mean "create a new concrete Template
            Method instance, add the new feature to its hook functions, and it
            gets Feature X automatically."

            Those who fear YAGNI tells them they must behave as if they don't
            know how to generalize need only look to the other, supporting rules
            in XP.

            --
            Phlip
            ======= http://users.deltanet.com/~tegan/home.html =======
          • Ron Jeffries
            ... Yes, right on! In fact, the rules of code simplicity would have you remove the duplication as soon as it is noticed, even without a new requirement. The
            Message 5 of 5 , Jan 8, 2000
              At 03:48 PM 1/8/2000 -0800, you wrote:
              >I have three big functions, each showing the same control flow
              >shape.
              >
              >My employer bio-peripheral tells me to add Feature X to all three
              >functions.
              >
              >OnceAndOnlyOnce sez I should start by expressing the control flow of
              >all three functions into one, using the Template Method DP. Then I
              >write Feature X once, in the control flow function that dispatches
              >to the virtual hook functions.
              >
              >Because OnceAndOnlyOnce sez I need it, YAGNI does not apply.

              Yes, right on! In fact, the rules of code simplicity would have you remove
              the duplication as soon as it is noticed, even without a new requirement.
              The rule Do the simplest thing that could possibly work means that the code
              must express all ideas needing expression, contain no duplication, minimize
              number of classes, minimize number of methods. So in fact all the objects
              with similar control flow should have been reduced.

              I was struck at the XP Immersion by how far Kent will go with this. He will
              remove control duplications that are even ALMOST alike, and it seems always
              to make things better.

              Good example!

              Ron Jeffries
              Extreme Programming Training and Consultation
              ronjeffries@...
              web pages: http://www.XProgramming.com, http://www.armaties.com
              pgp key: http://www.armaties.com/pgpkey.htm
            Your message has been successfully submitted and would be delivered to recipients shortly.