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

[extremeprogramming] Re: only code what you need today - rubb ish !

Expand Messages
  • Ron Jeffries
    ... One of them is. However, you have to do the other ones, as Zhon so nicely points out above. ... I d never code for the future, always code for the task I
    Message 1 of 12 , Feb 1, 2000
    • 0 Attachment
      At 12:44 PM 2/1/2000 -0500, you wrote:
      >Isnt that what XP states, or did I misread/misunderstand what Kent wrote in
      >his book? Isnt one of the XP principles - code for today, ie the simplest
      >solution to your immediate requirement?

      One of them is. However, you have to do the other ones, as Zhon so nicely
      points out above.

      >I fully appreciate that if you are going to add some new functionality in
      >say, 2 weeks, then maybe you should code for that new addition, but at what
      >point do you call the cut-off. How long is ok to code for - 1 week, 1 month,
      >an iteration?

      I'd never code for the future, always code for the task I have in hand
      RIGHT NOW. Never code for tomorrow or even this afternoon. Then refactor. I
      tried it and it works better than those immense design skills for which I'm
      justly famous. Very interesting.

      Regards,



      Ron Jeffries
      Extreme Programming Training and Consultation
      www.XProgramming.com
    • Michael C. Feathers
      ... From: Joshua Kerievsky ... abstraction ... Patterns ... I agree. One fun thing to do with patterns is to unfold them. Image
      Message 2 of 12 , Feb 1, 2000
      • 0 Attachment
        ----- Original Message -----
        From: Joshua Kerievsky <joshua@...>
        > Let's also help our less experienced XP programmers find those
        abstraction
        > by advising the following:
        >
        > When adding abstractions to make your designs simpler, consider
        Patterns
        > that could best meet your needs. If you find such a Pattern, start by
        > implementing it in the simplest possible way.

        I agree. One fun thing to do with patterns is to
        unfold them. Image what a class would look
        like if it didn't have a visitor, or if you didn't
        share interface across a composite and
        its components.

        Doing that gives a feel for the problem that leads
        to the pattern.. often it is duplication of
        something: code, interface, etc. Other
        times it is just clarity.. this class is doing
        to much, if we break things in this way,
        we get separation.. and a pattern!

        Michael

        ---------------------------------------------------
        Michael Feathers mfeathers@...
        Object Mentor Inc. www.objectmentor.com
        Training/Mentoring/Development
        -----------------------------------------------------
        "You think you know when you can learn, are more sure when
        you can write, even more when you can teach, but certain when
        you can program. " - Alan Perlis
      • Joshua Kerievsky
        ... Yes, in the past 6-months I ve been doing just that and challenging folks in my Design Patterns Workshops to do the same. I call this activity deGoFing. In
        Message 3 of 12 , Feb 1, 2000
        • 0 Attachment
          >I agree. One fun thing to do with patterns is to
          >unfold them. Image what a class would look
          >like if it didn't have a visitor, or if you didn't
          >share interface across a composite and
          >its components.

          Yes, in the past 6-months I've been doing just that and challenging folks
          in my Design Patterns Workshops to do the same.

          I call this activity deGoFing.

          In a paper I wrote for XP2000, I deGoFed some JUnit code that uses
          Decorator. The deGoFed code looked mighty ugly.

          If I saw that code, I'd know how to use Decorator to make it simpler and
          cleaner. In other words, I'd see a target for my refactorings. On the
          other hand, an inexperienced programmer, who is totally into Refactoring
          and all of this wonderful XP stuff, but who doesn't know Patterns, will
          not, IMHO, refactor their way to a Decorator solution. What will they come
          up with? Hopefully something that is simple and clean. But I'd feel a
          whole lot better if they knew some Patterns, and were continually learning
          new ones.

          >Doing that gives a feel for the problem that leads
          >to the pattern.. often it is duplication of
          >something: code, interface, etc. Other
          >times it is just clarity.. this class is doing
          >to much, if we break things in this way,
          >we get separation.. and a pattern!

          Yes, one of the problems we have with Patterns today is that the PROBLEMs
          that Patterns solve aren't clearly defined in the Patterns literature.

          See http://industriallogic.com/pulse/20000130.html

          regards
          jk

          _______________________________
          Industrial Logic, Inc.
          Joshua Kerievsky, founder
          mailto:joshua@...
          http://industriallogic.com
          415-292-6266
          415-292-6267 (fax)
        • Phil Goodwin
          ... I just spent an evening with a guy who se been pairing with Don Roberts (of refactoring browser fame) for the last week. It turns out that Don doesn t
          Message 4 of 12 , Feb 1, 2000
          • 0 Attachment
            At 12:28 PM 2/1/00 -0600, Robert C. Martin wrote:
            > > From: Michael C. Feathers [mailto:mfeathers@...]
            >
            > > Sure, if you only write the simplest solution to your
            > > immediate requirement -- and that is all that you do,
            > > you will end up in trouble.
            > >
            > > Don't do that.
            >
            > > -----Original Message-----
            > > From: Pratt, Nick [mailto:npratt@...]
            > >
            > > Question:
            > > =========
            > >
            > > Isnt that what XP states, or did I misread/misunderstand what
            > > Kent wrote in
            > > his book? Isnt one of the XP principles - code for today, ie
            > > the simplest
            > > solution to your immediate requirement?
            >
            >Not quite. Kent recommends that you consider the simplest solution
            >first. Assume simplicity. If you *know* that the simplest solution is
            >inadequate then extrapolate to the simplest solution that you *is*
            >adequate. XP advises against speculation. Don't gamble with your
            >design by trying to guess what abstractions are best. Let the evolution
            >of the project prove to you what abstractions are best.
            >
            >Mike Feathers said it best. Only add abstraction when it makes the
            >design simpler.
            >
            >One of the rules of XP is merciless refactoring. It is not enough that
            >the code work. It must also be the simplest and clearest that it can
            >be. So, in an XP project, if a developer found an area of the code that
            >could be simplified by adding an abstraction, he would add the
            >abstraction. If the developer found an area of code that could be
            >simplified by removing an abstraction, he would remove the abstraction.

            I just spent an evening with a guy who'se been pairing with Don Roberts (of
            refactoring browser fame) for the last week. It turns out that Don doesn't
            generalize code until the third (not second) time he's written the same
            thing. Apparently he feels that maintaining two copies of the same code is
            cheaper than pre-mature generalization and that three data points lead to
            better formed abstractions. Just an interesting data point.

            Phil
          • Kent Beck
            Nick- How long is ok to code [ahead] for - 1 week, 1 month, an iteration? You ll have to run that experiment for yourself. When I ran the experiment myself,
            Message 5 of 12 , Feb 2, 2000
            • 0 Attachment
              Nick-

              "How long is ok to code [ahead] for - 1 week, 1 month, an iteration?"

              You'll have to run that experiment for yourself. When I ran the experiment
              myself, confirmed in several team projects since, the optimal answer was
              about 0. This test case I code for. The next test case I
              code/design/analyze/test for when I get this one done. YMMV, but do try the
              experiment.

              Kent
            • Lorne Malec
              Kent, How about the word concise instead of simple ? Lorne
              Message 6 of 12 , Feb 2, 2000
              • 0 Attachment
                Kent,

                How about the word "concise" instead of "simple"?

                Lorne

                Kent Beck wrote:

                > Let's review the rules. In order:
                > 1. Run all the test cases
                > 2. Communicate everything you need to communicate
                > 3. No duplication
                > 4. Fewest possible classes and methods
                >
                > If you did something simple, it meets the rules. If the next person coming
                > along copies some of your code into their class, it doesn't meet the rules.
                > Don't do that.
                >
                > Martin tells me that my definition of "simple" isn't clear. I think perhaps
                > the problem is that I shouldn't use the word "simple". Something like
                > "normalized" or "factored" is better, but it doesn't capture the
                > communication aspect.
                >
                > Kent
                >
                > ------------------------------------------------------------------------
                > To Post a message, send it to: extremeprogramming@...
                >
                > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                >
                > ------------------------------------------------------------------------
                > GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 2.9%
                >
                > Intro or 9.9% Fixed APR and no hidden fees. Apply NOW!
                > http://click.egroups.com/1/915/0/_/263270/_/949517567/
                >
                > -- Check out your group's private Chat room
                > -- http://www.egroups.com/ChatPage?listName=extremeprogramming&m=1
              • Michael C. Feathers
                ... From: Kent Beck ... coming ... rules. ... perhaps ... It is interesting to notice how many of the smells in the book deal directly or
                Message 7 of 12 , Feb 2, 2000
                • 0 Attachment
                  ----- Original Message -----
                  From: Kent Beck <kentbeck@...>
                  > Let's review the rules. In order:
                  > 1. Run all the test cases
                  > 2. Communicate everything you need to communicate
                  > 3. No duplication
                  > 4. Fewest possible classes and methods
                  >
                  > If you did something simple, it meets the rules. If the next person
                  coming
                  > along copies some of your code into their class, it doesn't meet the
                  rules.
                  > Don't do that.
                  >
                  > Martin tells me that my definition of "simple" isn't clear. I think
                  perhaps
                  > the problem is that I shouldn't use the word "simple". Something like
                  > "normalized" or "factored" is better, but it doesn't capture the
                  > communication aspect.

                  It is interesting to notice how many of the smells in the book
                  deal directly or indirectly with the communicative aspects:

                  Duplicated code:
                  the duplicated code is a lie because you think changing it
                  there changes it everywhere.
                  Long Method
                  Large Class
                  Long Parameter List
                  all are hard to understand
                  Divergent Change
                  what is this classes's responsibility anyway?
                  Shotgun Surgery
                  how come the code isn't telling me where
                  I need to change it?
                  the list goes on..

                  As a matter of personal preference, I'd much rather have code
                  that is simple to understand than simple in any other way.
                  But, shooting directly for clear code is error-prone so
                  we evolve it by simple steps.

                  Kent, are there any cases where having more classes
                  or methods would make things clearer, but you'd
                  reduce them? Aside from reducing duplication?

                  Maybe clarity is the goal and we get there in
                  simple steps?

                  Michael

                  ---------------------------------------------------
                  Michael Feathers mfeathers@...
                  Object Mentor Inc. www.objectmentor.com
                  Training/Mentoring/Development
                  -----------------------------------------------------
                  "You think you know when you can learn, are more sure when
                  you can write, even more when you can teach, but certain when
                  you can program. " - Alan Perlis
                • Kent Beck
                  Mike- Kent, are there any cases where having more classes or methods would make things clearer, but you d reduce them? Aside from reducing duplication? No.
                  Message 8 of 12 , Feb 2, 2000
                  • 0 Attachment
                    Mike-

                    "Kent, are there any cases where having more classes
                    or methods would make things clearer, but you'd
                    reduce them? Aside from reducing duplication?"

                    No. You are responsible for communicating with your fellow programmers. A
                    classic example is this method:

                    highlight: aRectangle
                    self reverse: aRectangle

                    You could inline this method and not change any test results. However, you
                    are using this method to communicate that the way we highlight things in
                    this class is to reverse them. Intent/implementation. So you can't inline
                    it.

                    Reducing duplication always makes things clearer, just not always at the
                    moment. If there is an abstraction waiting to be discovered, eliminating
                    duplication might obscure control flows or responsibilities temporarily.
                    When you get the insight, the system as a whole becomes clearer than it was
                    before.

                    When you and the code disagree, the code is right.

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