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

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

Expand Messages
  • Thomas Matelich
    zhon johansen wrote: original article:http://www.egroups.com/group/extremeprogramming/?start =1178 ... and probably should ... probably don t
    Message 1 of 20 , Feb 1, 2000
      zhon johansen <zho-@...> wrote:
      original article:http://www.egroups.com/group/extremeprogramming/?start
      =1178
      > This message is an example of how one XP practice in isolation can
      and probably should
      > be attacked. XP is a tightly knit collection of Values and Practices.
      >
      > Your question assumes you don't do
      > *refactoring* to keep the design elegant, which means you
      probably don't have
      > *unit tests* to catch mistakes. You are probably not
      > *pair programming* to give you confidence. You are also probably
      missing an
      > *onsite customer* telling you the business requirements and that
      missing customer
      > is probably not writing
      > *functional tests* so you can know when you are finished...
      >
      > HTH,
      >
      > Zhon
      >

      One more important factor in this problem is communication. If there
      was good communication, developer B would talk to developer A and find
      out that there is something that could be refactored into what he needs.
    • Ron Jeffries
      ... As I read the text and walk the walk, it means exactly that: DO the simplest thing that could possibly work. See, for example: p 38: Treat every problem as
      Message 2 of 20 , Feb 1, 2000
        At 12:17 PM 2/1/2000 -0600, you wrote:
        >BTW, XP doesn't recommend that you DO the simplest thing that could
        >work. XP recommends that you consider WHAT the simplest thing that
        >could possible work might be, and then extrapolate from there. Assume
        >simplicity first.

        As I read the text and walk the walk, it means exactly that: DO the
        simplest thing that could possibly work. See, for example:

        p 38: Treat every problem as if it can be solved with ridiculous simplicity.

        p 103: The design strategy in XP is to always have the simplest design that
        runs the current test suite.

        p 104: We should assume that the simplest design we can imagine possibly
        working will work. This will give us time to do a thorough job in case the
        simples design doesn't work.

        Of course, one often falls short of the goal of always doing the simplest
        thing that could possibly work. Sometimes fear is just too much. Sometimes
        we don't think of the simplest thing until later. Then the rules of code
        simplicity encourage us to reduce the system back to where it belongs.

        Regards,

        Ron Jeffries
        Extreme Programming Training and Consultation
        www.XProgramming.com
      • Joshua Kerievsky
        Robert Martin writes ... Wiki has had a page called DoTheSimplestThingThatCouldPossiblyWork for well over a year now, and the expression has certainly made its
        Message 3 of 20 , Feb 1, 2000
          Robert Martin writes
          >>BTW, XP doesn't recommend that you DO the simplest thing that could
          >>work. XP recommends that you consider WHAT the simplest thing that
          >>could possible work might be, and then extrapolate from there. Assume
          >>simplicity first.

          Ron Jeffries responds:
          >As I read the text and walk the walk, it means exactly that: DO the
          >simplest thing that could possibly work.

          Wiki has had a page called DoTheSimplestThingThatCouldPossiblyWork for well
          over a year now, and the expression has certainly made its way into the
          culture. However, Kent recently wrote in an email thread I exchanged with him:
          ----
          Note that I never said "do the simplest thing that could possibly work".
          That would be stupid. I try to get people to think in terms of simplicity,
          hence the phrasing "what is the simplest..." It's a mantra.
          ----

          I personally like the question better than the statement. The question is
          an invitation to think - it might lead to a 10 minute round-table on just
          what is the simplest thing. The statement form (Do The...) may not invite
          enough reflection.

          -jk





          regards
          jk


          _______________________________
          Industrial Logic, Inc.
          Joshua Kerievsky, founder
          mailto:joshua@...
          http://industriallogic.com
          415-292-6266
          415-292-6267 (fax)
        • Ron Jeffries
          I could be mistaken, but I m sure Kent did tell the C3 team exactly that. Of course a lot of what we told them has been refined. Kent is usually more extreme
          Message 4 of 20 , Feb 1, 2000
            I could be mistaken, but I'm sure Kent did tell the C3 team exactly that.
            Of course a lot of what we told them has been refined. Kent is usually more
            extreme than I am, but in my simple way I've just been doing what he told
            me and I've never gone wrong yet with the simplest thing "that could
            possibly work".

            I can't help thinking, so I don't worry about accidentally forgetting to do
            so. Perhaps I should. What were we talking about?

            Oh, yeah, simplicity. Certainly it is a mantra. But when you do it, it
            seems to work. Kent should try it ... ;->

            Ron

            At 12:08 PM 2/1/2000 -0800, you wrote:
            >Robert Martin writes
            > >>BTW, XP doesn't recommend that you DO the simplest thing that could
            > >>work. XP recommends that you consider WHAT the simplest thing that
            > >>could possible work might be, and then extrapolate from there. Assume
            > >>simplicity first.
            >
            >Ron Jeffries responds:
            > >As I read the text and walk the walk, it means exactly that: DO the
            > >simplest thing that could possibly work.
            >
            >Wiki has had a page called DoTheSimplestThingThatCouldPossiblyWork for well
            >over a year now, and the expression has certainly made its way into the
            >culture. However, Kent recently wrote in an email thread I exchanged with him:
            >----
            >Note that I never said "do the simplest thing that could possibly work".
            >That would be stupid. I try to get people to think in terms of simplicity,
            >hence the phrasing "what is the simplest..." It's a mantra.
            >----
            >
            >I personally like the question better than the statement. The question is
            >an invitation to think - it might lead to a 10 minute round-table on just
            >what is the simplest thing. The statement form (Do The...) may not invite
            >enough reflection.
            >
            >-jk
            >
            >
            >
            >
            >
            >regards
            >jk
            >
            >
            >_______________________________
            >Industrial Logic, Inc.
            >Joshua Kerievsky, founder
            >mailto:joshua@...
            >http://industriallogic.com
            >415-292-6266
            >415-292-6267 (fax)
            >
            >
            >------------------------------------------------------------------------
            >To Post a message, send it to: extremeprogramming@...
            >To Unsubscribe, send a blank message to:
            >extremeprogramming-unsubscribe@...
            >
            >------------------------------------------------------------------------
            >Get what you deserve with NextCard Visa! Rates as low as 2.9%
            >Intro or 9.9% Fixed APR, online balance transfers, Rewards Points,
            >no hidden fees, and much more! Get NextCard today and get the
            >credit youdeserve! Apply now! Get your NextCard Visa at:
            >http://click.egroups.com/1/912/0/_/263270/_/949435715/
            >
            >-- 20 megs of disk space in your group's Document Vault
            >-- http://www.egroups.com/docvault/extremeprogramming/?m=1
            >


            Ron Jeffries
            Extreme Programming Training and Consultation
            www.XProgramming.com
          • Michael C. Feathers
            ... From: Joshua Kerievsky ... well ... the ... work . ... simplicity, ... I like how Chet Hedrickson of the C3 team put it on
            Message 5 of 20 , Feb 1, 2000
              ----- Original Message -----
              From: Joshua Kerievsky <joshua@...>
              > Wiki has had a page called DoTheSimplestThingThatCouldPossiblyWork for
              well
              > over a year now, and the expression has certainly made its way into
              the
              > culture. However, Kent recently wrote in an email thread I exchanged
              with him:
              > ----
              > Note that I never said "do the simplest thing that could possibly
              work".
              > That would be stupid. I try to get people to think in terms of
              simplicity,
              > hence the phrasing "what is the simplest..." It's a mantra.
              > ----

              I like how Chet Hedrickson of the C3 team put it on Wiki:
              "The rule is, 'Do the simplest thing that could possibly
              work', not the most stupid."

              Whenever I can draw the distinction between the simplicity
              and stupidity, I make the effort and shoot for the former.

              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
            • Phlip
              From: ... your ... If you only type just enough to change the code the tiniest amount to satisfy one requirement, you l
              Message 6 of 20 , Feb 1, 2000
                From: <cbrooksbank@...>


                > If you always write the simplist ( and the most specific ) solution to
                your
                > current immediate requirement you will generate problems.

                If you only type just enough to change the code the tiniest amount to
                satisfy one requirement, you'l produce bad code.

                If you also apply OnceAndOnlyOnce and UnitTestFirst (the supporting
                practices for DTSTTCPW and YAGNI), you can always try to leave the code
                (and the UnitTests) in their simplest, cleanest state.

                If you apply any of the 12 canonical XP processes extremely but in
                isolation from the others you'l get a bad result. Kent's book XPE covers
                this fully.

                > The next guy that comes along with a slightly different problem will
                write his
                > own specific class.

                Nope. He'd have broken OAOO. Sacrifice him to an XP principle at their
                next love fest.

                Phlip
                ======= http://users.deltanet.com/~tegan/home.html =======
              • William Rutiser
                Some well known aircraft designer once said Simplificate and add lightness . This is one of those things that is easier to say than do. Changes that restrict
                Message 7 of 20 , Feb 1, 2000
                  Some well known aircraft designer once said "Simplificate and add
                  lightness". This is one of those things that is easier to say than do.

                  Changes that restrict or constrain future change are less simple in
                  their effects than changes that don't.


                  Bill Rutiser
                  wru@...
                • Chris Berry
                  Greetings, A buddy of mine just turned me on to an amazing tool for refactoring Java code. It is called Woodenchair (www.woodenchair.com). It allows you to
                  Message 8 of 20 , Feb 1, 2000
                    Greetings,

                    A buddy of mine just turned me on to an amazing tool for refactoring Java
                    code. It is called Woodenchair (www.woodenchair.com). It allows you to
                    Repackage Mercilessly. It catches *everything*, including even the JavaDocs.
                    And works flawlessly. We just took our semi-large code base (~500 classes)
                    and did a massive restructuring of it (including moving packages, files into
                    different packages, new levels in the hierarchy, etc.) It took about 10
                    minutes. Pretty cool. (I suppose y'all already knew all about it, but just
                    in case... )

                    Cheers,
                    --Chris

                    (And no, I don't have any affiliation w/ Woodenchair ;-)
                  • Phil Goodwin
                    ... Okay, sure. But what does simple mean anyway? Ron once said to use LOC as a metric for simplicity. Is that it? Is it the fewest number of methods?
                    Message 9 of 20 , Feb 1, 2000
                      "Michael C. Feathers" wrote:
                      >
                      > ----- Original Message -----
                      > From: Joshua Kerievsky <joshua@...>
                      > > Wiki has had a page called DoTheSimplestThingThatCouldPossiblyWork for
                      > well
                      > > over a year now, and the expression has certainly made its way into
                      > the
                      > > culture. However, Kent recently wrote in an email thread I exchanged
                      > with him:
                      > > ----
                      > > Note that I never said "do the simplest thing that could possibly
                      > work".
                      > > That would be stupid. I try to get people to think in terms of
                      > simplicity,
                      > > hence the phrasing "what is the simplest..." It's a mantra.
                      > > ----
                      >
                      > I like how Chet Hedrickson of the C3 team put it on Wiki:
                      > "The rule is, 'Do the simplest thing that could possibly
                      > work', not the most stupid."
                      >
                      > Whenever I can draw the distinction between the simplicity
                      > and stupidity, I make the effort and shoot for the former.
                      >
                      > Michael

                      Okay, sure. But what does 'simple' mean anyway? Ron once said to use LOC
                      as a metric for simplicity. Is that it? Is it the fewest number of
                      methods? Classes? Function points? Is it the simplest to code? To
                      invent? To explain? Does simple mean fast? To me globals are about the
                      simplest scoping and lifetime management strategy, gotos are the
                      simplest control structure and arrays are the simplest collections. It
                      always seems simpler to grow an existing class than to build a new one.
                      So many "simple" things turn out to be headaches later.

                      What I personally have done, with some success, is to START with the
                      simplest thing that could possibly work and use "what seems easiest to
                      program" as my definition of "simple". This is an application of "make
                      it run, make it right, make it fast". After I've written it I test and
                      refactor (making things I touch "right") until it works, and then I
                      continue refactoring until the whole thing is "right". In practice this
                      means that I start out using a lot of primitive tools that are easily
                      manipulated and end up replacing them with tools that are specialized
                      for the kinds of manipulations that I actually end up doing.

                      I don't know if that's the behavior that the advice was supposed to
                      inspire or even if I actually get the final version of the code written
                      any faster. I can say, though, that it gets my relationship with the
                      code started pretty quickly which keeps my interest high and makes
                      things a little more fun.

                      --
                      Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951
                    • Chris Berry
                      Greetings, I would like to suggest that the ListServe shorten the email tag it applies to email from this list. What about, say, [xp]. Then we can see more of
                      Message 10 of 20 , Feb 1, 2000
                        Greetings,

                        I would like to suggest that the ListServe shorten the email tag it applies
                        to email from this list. What about, say, [xp]. Then we can see more of
                        what is important on the Subject line of our email readers.

                        Cheers,
                        -- Chris
                      • Michael C. Feathers
                        ... From: Phil Goodwin ... LOC ... one. ... It seems that there are a lot of forces. Ideally a piece of code should be simple to
                        Message 11 of 20 , Feb 1, 2000
                          ----- Original Message -----
                          From: Phil Goodwin <phil.goodwin@...>
                          > Okay, sure. But what does 'simple' mean anyway? Ron once said to use
                          LOC
                          > as a metric for simplicity. Is that it? Is it the fewest number of
                          > methods? Classes? Function points? Is it the simplest to code? To
                          > invent? To explain? Does simple mean fast? To me globals are about the
                          > simplest scoping and lifetime management strategy, gotos are the
                          > simplest control structure and arrays are the simplest collections. It
                          > always seems simpler to grow an existing class than to build a new
                          one.
                          > So many "simple" things turn out to be headaches later.

                          It seems that there are a lot of forces. Ideally a piece of code
                          should be simple to understand, simple to change, and simple to
                          code.

                          One thing I've discovered when trying to do what Kent and
                          Ron talk about is that good object factoring allows me to strike a
                          balance between those three things. For instance, when you
                          extract a class, you get to introduce a name which conveys intent
                          a bit more. If the extraction was really warranted, two classes are
                          easier to understand on their own and together after the extraction.
                          Each resulting class is also closed under more changes. But
                          isn't it easier to code the larger class? Yes, but if it costs too much
                          on the other two prongs of simplicity, you refactor.

                          I just think that the OO flavor of simplicity is different. Sometimes
                          I look at some very clear procedural code and realize that it
                          conveys intent very well, but it would fail on other two prongs
                          of simplicity. Things like 'replace conditional with polymorphism'
                          may not be too simple from the procedural point of view, but
                          once changeability and dependency management are taken
                          into account, it is a clear win. Simple designs are easily
                          extended. I remember when I read Bob Martin's description
                          of the Dependency Inversion Principle years ago, I realized
                          this is why objects are different. Each interface is a point of
                          variation. You can have a great deal of flexibility without
                          making all sorts of "hooks."

                          > What I personally have done, with some success, is to START with the
                          > simplest thing that could possibly work and use "what seems easiest to
                          > program" as my definition of "simple". This is an application of "make
                          > it run, make it right, make it fast". After I've written it I test and
                          > refactor (making things I touch "right") until it works, and then I
                          > continue refactoring until the whole thing is "right". In practice
                          this
                          > means that I start out using a lot of primitive tools that are easily
                          > manipulated and end up replacing them with tools that are specialized
                          > for the kinds of manipulations that I actually end up doing.

                          Yeah, I do that too. It is a great way to get started. I usually stick
                          a spike in the ground.. some interface that I can test behind and
                          then write brute force code that I can refactor into better
                          structure as it occurs to me.


                          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
                        • Phil Goodwin
                          ... My friend who is receiving XP tutoring from Don Robert says that they are literally programming the simplest thing that could possibly make the simplest of
                          Message 12 of 20 , Feb 1, 2000
                            At 06:01 PM 2/1/00 -0500, Michael C. Feathers wrote:
                            >----- Original Message -----
                            >From: Phil Goodwin <phil.goodwin@...>
                            > > Okay, sure. But what does 'simple' mean anyway?

                            >It seems that there are a lot of forces. Ideally a piece of code
                            >should be simple to understand, simple to change, and simple to
                            >code.
                            >
                            >One thing I've discovered when trying to do what Kent and
                            >Ron talk about is that good object factoring allows me to strike a
                            >balance between those three things. For instance, when you
                            >extract a class, you get to introduce a name which conveys intent
                            >a bit more. If the extraction was really warranted, two classes are
                            >easier to understand on their own and together after the extraction.
                            >Each resulting class is also closed under more changes. But
                            >isn't it easier to code the larger class? Yes, but if it costs too much
                            >on the other two prongs of simplicity, you refactor.

                            My friend who is receiving XP tutoring from Don Robert says that they are
                            literally programming the simplest thing that could possibly make the
                            simplest of tests work. That's simplest as in simplest to program and also
                            the simplest problem. While listening to him talk about it tonight the
                            ambiguity of the notion of simplicity fell away. What I got was essentially
                            that if the initial code had any chance at all of being the least bit
                            interesting it was too complicated. All the interesting/complex stuff they
                            were doing was coming from refactoring.

                            >I just think that the OO flavor of simplicity is different. Sometimes
                            >I look at some very clear procedural code and realize that it
                            >conveys intent very well, but it would fail on other two prongs
                            >of simplicity. Things like 'replace conditional with polymorphism'
                            >may not be too simple from the procedural point of view, but
                            >once changeability and dependency management are taken
                            >into account, it is a clear win. Simple designs are easily
                            >extended. I remember when I read Bob Martin's description
                            >of the Dependency Inversion Principle years ago, I realized
                            >this is why objects are different. Each interface is a point of
                            >variation. You can have a great deal of flexibility without
                            >making all sorts of "hooks."

                            Flexibility and understandability are forces that are at odds with
                            simplicity. I think that simplicity is a starting point and is used as a
                            currency with which to buy expressiveness and flexibility. You buy
                            expressiveness after you've got something to work and are about to leave it
                            behind and you buy flexibility just as it's needed. At least that's my
                            understanding for today.

                            Phil
                          • Kent Beck
                            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
                            Message 13 of 20 , Feb 2, 2000
                              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
                            • Michael C. Feathers
                              ... From: Phil Goodwin ... Sometimes ... a ... leave it ... Yes, there are all sorts of definitions of simplicity. I like to take the
                              Message 14 of 20 , Feb 2, 2000
                                ----- Original Message -----
                                From: Phil Goodwin <pgoodwin@...>
                                > At 06:01 PM 2/1/00 -0500, Michael C. Feathers wrote:
                                > >I just think that the OO flavor of simplicity is different.
                                Sometimes
                                > >I look at some very clear procedural code and realize that it
                                > >conveys intent very well, but it would fail on other two prongs
                                > >of simplicity. Things like 'replace conditional with polymorphism'
                                > >may not be too simple from the procedural point of view, but
                                > >once changeability and dependency management are taken
                                > >into account, it is a clear win. Simple designs are easily
                                > >extended. I remember when I read Bob Martin's description
                                > >of the Dependency Inversion Principle years ago, I realized
                                > >this is why objects are different. Each interface is a point of
                                > >variation. You can have a great deal of flexibility without
                                > >making all sorts of "hooks."
                                >
                                > Flexibility and understandability are forces that are at odds with
                                > simplicity. I think that simplicity is a starting point and is used as
                                a
                                > currency with which to buy expressiveness and flexibility. You buy
                                > expressiveness after you've got something to work and are about to
                                leave it
                                > behind and you buy flexibility just as it's needed. At least that's my
                                > understanding for today.

                                Yes, there are all sorts of definitions of simplicity. I like to take
                                the broad one, because I've noticed that 'simple to understand',
                                'simple to implement', and 'simple to change' all feed into each
                                other when I am going on the right track. The Venn diagram
                                has such a large intersection that I don't feel that one
                                happens at much expense to the others. Maybe I'm not
                                being introspective enough on this point.

                                That said, I agree about starting with 'simple to implement.'
                                Of the three, though, I like to shoot for 'simple to understand'
                                because it offers the most bang for the buck.


                                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
                              Your message has been successfully submitted and would be delivered to recipients shortly.