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

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

Expand Messages
  • 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 1 of 5 , Jan 4, 2000
    • 0 Attachment
      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 2 of 5 , Jan 8, 2000
      • 0 Attachment
        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 3 of 5 , Jan 8, 2000
        • 0 Attachment
          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.