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

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

Expand Messages
  • cbrooksbank@citynetworks.co.uk
    If you always write the simplist ( and the most specific ) solution to your current immediate requirement you will generate problems. The next guy that comes
    Message 1 of 20 , Feb 1, 2000
    • 0 Attachment
      If you always write the simplist ( and the most specific ) solution to your
      current immediate requirement you will generate problems.
      The next guy that comes along with a slightly different problem will write his
      own specific class. It would take longer to work back looking for a way
      to generlalise the solution at a higher class level. With lots of programmers
      you get lots of classes over time, likely some bits will be cut and paste
      from other classes. When a bug is fixed or implementation improved its only
      fixed in some of these bits of code. A new maintenance programmer has lots of
      bits
      of code to work with instead of just one. Some will be subtly different with
      their own bugs. Your best coders will hate you for making them produce inelegant
      designs
      and leave for other companys. Tell me Im wrong ( Im sure you will ) . . .
      **********************************************************************
      Any views expressed in this message are the sender's own, and do not
      represent the views of City Networks Limited, except where the sender
      specifically states them to be the views of City Networks Limited.
      **********************************************************************
    • Michael C. Feathers
      ... From: ... your ... write his ... way ... programmers ... paste ... only ... lots of ... different with ... inelegant ... .
      Message 2 of 20 , Feb 1, 2000
      • 0 Attachment
        ----- Original Message -----
        From: <cbrooksbank@...>
        > If you always write the simplist ( and the most specific ) solution to
        your
        > current immediate requirement you will generate problems.
        > The next guy that comes along with a slightly different problem will
        write his
        > own specific class. It would take longer to work back looking for a
        way
        > to generlalise the solution at a higher class level. With lots of
        programmers
        > you get lots of classes over time, likely some bits will be cut and
        paste
        > from other classes. When a bug is fixed or implementation improved its
        only
        > fixed in some of these bits of code. A new maintenance programmer has
        lots of
        > bits
        > of code to work with instead of just one. Some will be subtly
        different with
        > their own bugs. Your best coders will hate you for making them produce
        inelegant
        > designs
        > and leave for other companys. Tell me Im wrong ( Im sure you will ) .
        . .

        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.

        On the other hand, if you write the simplest thing,
        and are constantly removing duplicate code, you
        will end up with a simple elegant
        system that is tuned to the problems it solves.

        Will it take longer to work back looking for a
        way to generalize something? I don't think so.
        Generalizing is easy. Too easy. The hard part
        is coming up with generalizations which
        survive application changes well. Until you
        confront the changes, they are hypothetical.

        A good rule of thumb is to never generalize
        something unless it makes things simpler.
        This generally means that you are removing
        duplication, or separating things so that each
        can be understood easier.

        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
      • Zhon Johansen
        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.
        Message 3 of 20 , Feb 1, 2000
        • 0 Attachment
          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

          PS shamelessly stolen from and earlier post of Rons, thanks Ron

          cbrooksbank@... wrote:

          > If you always write the simplist ( and the most specific ) solution to your
          > current immediate requirement you will generate problems.
          > The next guy that comes along with a slightly different problem will write his
          > own specific class. It would take longer to work back looking for a way
          > to generlalise the solution at a higher class level. With lots of programmers
          > you get lots of classes over time, likely some bits will be cut and paste
          > from other classes. When a bug is fixed or implementation improved its only
          > fixed in some of these bits of code. A new maintenance programmer has lots of
          > bits
          > of code to work with instead of just one. Some will be subtly different with
          > their own bugs. Your best coders will hate you for making them produce inelegant
          > designs
          > and leave for other companys. Tell me Im wrong ( Im sure you will ) . . .
          > **********************************************************************
          > Any views expressed in this message are the sender's own, and do not
          > represent the views of City Networks Limited, except where the sender
          > specifically states them to be the views of City Networks Limited.
          > **********************************************************************
          >
          > ------------------------------------------------------------------------
          > 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 you deserve! Apply now! Get your NextCard Visa at:
          > http://click.egroups.com/1/913/0/_/263270/_/949423973/
          >
          > -- Talk to your group with your own voice!
          > -- http://www.egroups.com/VoiceChatPage?listName=extremeprogramming&m=1
        • cbrooksbank@citynetworks.co.uk
          Zhon, Your comment makes a lot of sense. I will go back and read the rest of the principles of XP ( which I have only just come across ). I guess XP assumes
          Message 4 of 20 , Feb 1, 2000
          • 0 Attachment
            Zhon,

            Your comment makes a lot of sense. I will go back and read the rest of the
            principles of XP ( which I have only just come across ).

            I guess XP assumes code gets qa'd by developers other than the author at
            regular intervals to get around cut-and-paste code and to check that
            assumptions made at time code was written still apply.






            Zhon Johansen <zhon@...> on 01/02/2000 17:16:44

            Please respond to extremeprogramming@egroups.com

            To: extremeprogramming@egroups.com
            cc: (bcc: Chris Brooksbank/London/CityNetworks)

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



            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

            PS shamelessly stolen from and earlier post of Rons, thanks Ron

            cbrooksbank@... wrote:

            > If you always write the simplist ( and the most specific ) solution to your
            > current immediate requirement you will generate problems.
            > The next guy that comes along with a slightly different problem will write his
            > own specific class. It would take longer to work back looking for a way
            > to generlalise the solution at a higher class level. With lots of programmers
            > you get lots of classes over time, likely some bits will be cut and paste
            > from other classes. When a bug is fixed or implementation improved its only
            > fixed in some of these bits of code. A new maintenance programmer has lots of
            > bits
            > of code to work with instead of just one. Some will be subtly different with
            > their own bugs. Your best coders will hate you for making them produce
            inelegant
            > designs
            > and leave for other companys. Tell me Im wrong ( Im sure you will ) . . .
            > **********************************************************************
            > Any views expressed in this message are the sender's own, and do not
            > represent the views of City Networks Limited, except where the sender
            > specifically states them to be the views of City Networks Limited.
            > **********************************************************************
            >
            > ------------------------------------------------------------------------
            > 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 you deserve! Apply now! Get your NextCard Visa at:
            > http://click.egroups.com/1/913/0/_/263270/_/949423973/
            >
            > -- Talk to your group with your own voice!
            > -- http://www.egroups.com/VoiceChatPage?listName=extremeprogramming&m=1


            ------------------------------------------------------------------------
            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 0.0% Intro APR and no hidden fees.
            Apply NOW!
            http://click.egroups.com/1/967/0/_/263270/_/949425417/

            -- Easily schedule meetings and events using the group calendar!
            -- http://www.egroups.com/cal?listname=extremeprogramming&m=1
          • Robert C. Martin
            ... Not for today. The problems *may* come tomorrow. If on the other hand you try to anticipate tomorrows problems and protect yourself from them, you: 1)
            Message 5 of 20 , Feb 1, 2000
            • 0 Attachment
              > -----Original Message-----
              > From: cbrooksbank@...
              > [mailto:cbrooksbank@...]
              > Sent: Tuesday, February 01, 2000 10:52 AM
              > To: extremeprogramming@egroups.com
              > Subject: [extremeprogramming] only code what you need today -
              > rubbish !
              >
              >
              > If you always write the simplist ( and the most specific )
              > solution to your
              > current immediate requirement you will generate problems.

              Not for today. The problems *may* come tomorrow. If on the other hand
              you try to anticipate tomorrows problems and protect yourself from them,
              you:

              1) make the software bigger and more complex than it needs to be right
              now.

              2) will guess wrong part of the time and force the next guy to undo, or
              work around, what you did.

              3) will spend a lot of time worrying about things that may never happen.

              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.

              > The next guy that comes along with a slightly different
              > problem will write his
              > own specific class. It would take longer to work back looking
              > for a way
              > to generlalise the solution at a higher class level.

              It might indeed take longer. But the rules of XP force you to do it
              anyway. XP does not allow duplicate code in any form. Thus, when you
              find duplication, you must abstract it out.

              > With
              > lots of programmers
              > you get lots of classes over time, likely some bits will be
              > cut and paste
              > from other classes.

              Cut and paste is not allowed in XP because it is a form of duplication.
              The duplication must be factored out. We find that this makes us go
              faster in the long run.

              > When a bug is fixed or implementation
              > improved its only
              > fixed in some of these bits of code.

              Shouldn't happen in XP.

              > A new maintenance
              > programmer has lots of
              > bits
              > of code to work with instead of just one. Some will be subtly
              > different with
              > their own bugs. Your best coders will hate you for making
              > them produce inelegant
              > designs
              > and leave for other companys. Tell me Im wrong ( Im sure you
              > will ) . . .

              You aren't wrong. You just misunderstand XP. XP recommend that you do
              *exactly* what you recommend; with one exception. In XP we build the
              abstractions as soon as there is any duplication. Not when we suspect
              that there *might* be duplication. The rule in XP is "The second use
              pays for generality."


              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
            • Michael C. Feathers
              Nick, This is where things get dangerous in mailing lists. Below the last edit, I said that you end up in trouble if you don t surround doing the simplest
              Message 6 of 20 , Feb 1, 2000
              • 0 Attachment
                Nick,

                This is where things get dangerous in mailing
                lists. Below the last edit, I said that you end up in
                trouble if you don't surround 'doing the simplest
                thing with other practices.' The net result of a lot
                of little locally advantageous changes is a big
                ball of mud, if you don't refactoring and simplify
                along the way.

                "Simple" works at two levels: simple changes to
                add the functionality that you need and
                "simple" overall design. You maintain the
                latter by refactoring.

                So, being clearer. The answer is, yes, do the
                simplest thing. But do the other practices as
                well, especially the testing and refactoring,
                so that you do not end up with the cruft that
                the original poster mentioned.

                Regarding the other question, you code
                what you need for each test that you have
                to run to get the functionality that your
                customer needs for this iteration.

                Michael

                ----- Original Message -----
                From: Pratt, Nick <npratt@...>
                > -----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?

                ---------------------------------------------------
                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
              • Thomas Matelich
                zhon johansen wrote: original article:http://www.egroups.com/group/extremeprogramming/?start =1178 ... and probably should ... probably don t
                Message 7 of 20 , Feb 1, 2000
                • 0 Attachment
                  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 8 of 20 , Feb 1, 2000
                  • 0 Attachment
                    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 9 of 20 , Feb 1, 2000
                    • 0 Attachment
                      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 10 of 20 , Feb 1, 2000
                      • 0 Attachment
                        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 11 of 20 , Feb 1, 2000
                        • 0 Attachment
                          ----- 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 12 of 20 , Feb 1, 2000
                          • 0 Attachment
                            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 13 of 20 , Feb 1, 2000
                            • 0 Attachment
                              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 14 of 20 , Feb 1, 2000
                              • 0 Attachment
                                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 15 of 20 , Feb 1, 2000
                                • 0 Attachment
                                  "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 16 of 20 , Feb 1, 2000
                                  • 0 Attachment
                                    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 17 of 20 , Feb 1, 2000
                                    • 0 Attachment
                                      ----- 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 18 of 20 , Feb 1, 2000
                                      • 0 Attachment
                                        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 19 of 20 , Feb 2, 2000
                                        • 0 Attachment
                                          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 20 of 20 , Feb 2, 2000
                                          • 0 Attachment
                                            ----- 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.