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

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

Expand Messages
  • Pratt, Nick
    ... From: Michael C. Feathers [mailto:mfeathers@objectmentor.com] Sent: Tuesday, February 01, 2000 12:14 To: extremeprogramming@egroups.com Subject:
    Message 1 of 12 , Feb 1 9:44 AM
    • 0 Attachment
      -----Original Message-----
      From: Michael C. Feathers [mailto:mfeathers@...]
      Sent: Tuesday, February 01, 2000 12:14
      To: extremeprogramming@egroups.com
      Subject: [extremeprogramming] Re: only code what you need today -
      rubbish !

      [snip snip]

      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.

      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?

      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?

      Nick
    • Robert C. Martin
      ... Not quite. Kent recommends that you consider the simplest solution first. Assume simplicity. If you *know* that the simplest solution is inadequate then
      Message 2 of 12 , Feb 1 10:28 AM
      • 0 Attachment
        > 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.


        Robert C. Martin | "Uncle Bob" | Training Courses:
        Object Mentor Inc. | rmartin@... | OOD, Patterns, C++,
        Java,
        PO Box 85 | Tel: (800) 338-6716 | Extreme Programming.
        Grayslake IL 60030 | Fax: (847) 548-6853 |
        http://www.objectmentor.com

        "One of the great commandments of science is:
        'Mistrust arguments from authority.'" -- Carl Sagan
        >
        > 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?
        >
        > Nick
        >
        > --------------------------------------------------------------
        > ----------
        > To Post a message, send it to: extremeprogramming@...
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > --------------------------------------------------------------
        > ----------
        > FREE ADVICE FROM REAL PEOPLE! Xpertsite has thousands of experts who
        > are willing to answer your questions for FREE. Go to
        > Xpertsite today and
        > put your mind to rest.
        > http://click.egroups.com/1/1033/0/_/263270/_/949426948/
        >
        > -- Talk to your group with your own voice!
        > --
        http://www.egroups.com/VoiceChatPage?listName=extremeprogramming&m=1
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.