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

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

Expand Messages
  • Joshua Kerievsky
    ... Let s also help our less experienced XP programmers find those abstraction by advising the following: When adding abstractions to make your designs
    Message 1 of 12 , Feb 1 10:47 AM
    • 0 Attachment
      >Mike Feathers said it best. Only add abstraction when it makes the
      >design simpler.

      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.

      (Yes, that should generate some fine dialogues on this list!)

      best,
      joshua
      _______________________________
      Industrial Logic, Inc.
      Joshua Kerievsky, founder
      mailto:joshua@...
      http://industriallogic.com
      415-292-6266
      415-292-6267 (fax)
    • Barry Gervin
      Three Cheers for patterns. A friend of mind said it best when he commented about our profession compared to engineering. We ll never get close to the
      Message 2 of 12 , Feb 1 11:03 AM
      • 0 Attachment
        Three Cheers for patterns.

        A friend of mind said it best when he commented about our profession
        compared to engineering.

        "We'll never get close to the engineering discipline if we don't standardize
        our terminology and component patterns."

        If GM asks a supplier for Tire's, each other knows more or less what is
        required. If I ask you for a credit authorization module, we have to spell
        out every last part of the functionality and API.

        -----Original Message-----
        From: Joshua Kerievsky [mailto: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.

        joshua
      • 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 3 of 12 , Feb 1 11:18 AM
        • 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 4 of 12 , Feb 1 11:29 AM
          • 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 5 of 12 , Feb 1 12:25 PM
            • 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 6 of 12 , Feb 1 10:52 PM
              • 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 7 of 12 , Feb 2 10:50 AM
                • 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 8 of 12 , Feb 2 12:10 PM
                  • 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 9 of 12 , Feb 2 12:31 PM
                    • 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 10 of 12 , Feb 2 3:36 PM
                      • 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.