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

meaning of "could possibly work" clause

Expand Messages
  • Paul Campbell
    Heres a question for the house: what does simplest thing that could possibly work mean over and above just simplest thing ?. All it seems to do is exclude
    Message 1 of 22 , Jun 1 2:35 AM
    • 0 Attachment
      Heres a question for the house: what does "simplest thing that could
      possibly work" mean over and above just "simplest thing" ?. All it
      seems to do is exclude things which dont work, and what is the point
      of that in a TDD world ?.

      But worse than merely being tuatologous, to me it encourages
      missinterpretation of "simple" as easiest/quickest/most expedient and
      thus is not a phrase I would ever use myself to convey what I mean by
      "simplest".

      Paul.
    • Ron Jeffries
      ... If it couldn t possibly work, then one might not want to start out in that direction. Kent Beck used to ask what is the simplest thing that could possibly
      Message 2 of 22 , Jun 1 2:51 AM
      • 0 Attachment
        On Thursday, June 1, 2006, at 5:35:41 AM, Paul Campbell wrote:

        > Heres a question for the house: what does "simplest thing that could
        > possibly work" mean over and above just "simplest thing" ?. All it
        > seems to do is exclude things which dont work, and what is the point
        > of that in a TDD world ?.

        If it couldn't possibly work, then one might not want to start out
        in that direction.

        Kent Beck used to ask "what is the simplest thing that could
        possibly work," to help people get out of analysis paralysis and do
        something.

        I began to say "/Do/ the simplest thing that could possibly work,"
        for two reasons. First, the power of the idea is to do something
        simple enough to get started with, and second, I find it to be a
        strong move to start with something really simple, because often it
        works just fine.

        > But worse than merely being tuatologous, to me it encourages
        > missinterpretation of "simple" as easiest/quickest/most expedient and
        > thus is not a phrase I would ever use myself to convey what I mean by
        > "simplest".

        I can see how "simplest thing" could be misinterpreted in those
        ways, but not why "could possibly work" would make it worse as you
        seem to suggest.

        I like to use Kent Beck's definition of simple code. In priority
        order:

        1. Runs all the tests;
        2. Contains no duplication;
        3. Expresses all the code's design ideas;
        4. Minimizes entities (classes, methods, ...)/

        Ron Jeffries
        www.XProgramming.com
        Thousands of years ago, the first man discovered how to make fire.
        He was probably burned at the stake he had taught his brothers to
        light - Howard Roark (The Fountainhead, Ayn Rand)
      • Tony Byrne
        Hello Paul, Thursday, June 1, 2006, 10:35:41 AM, you wrote: PC Heres a question for the house: what does simplest thing that could PC possibly work mean
        Message 3 of 22 , Jun 1 3:10 AM
        • 0 Attachment
          Hello Paul,

          Thursday, June 1, 2006, 10:35:41 AM, you wrote:

          PC> Heres a question for the house: what does "simplest thing that could
          PC> possibly work" mean over and above just "simplest thing" ?. All it
          PC> seems to do is exclude things which dont work, and what is the point
          PC> of that in a TDD world ?.

          PC> But worse than merely being tuatologous, to me it encourages
          PC> missinterpretation of "simple" as easiest/quickest/most expedient and
          PC> thus is not a phrase I would ever use myself to convey what I mean by
          PC> "simplest".

          For me the form has always conveyed a meaning which seeks to
          distinguish between "simplistic" (bad, not thought through, poor
          design etc.) and "simple" (good, sufficient for today, cleanly
          implemented, etc.)

          You may believe that "could possibly work" is redundant, but there are
          probably plenty of developers and customers out there that need the
          help of that addendum. I find it reminds me to consider whether my
          simple solutions will actually cut it and whether the system will be
          in a better or worse state afterwards.

          I agree that it would be bad to give the impression that simple
          equates to the most expedient solution; I've regretted many of my own
          expedient solutions which were often just hacks. However, it's appears
          to be difficult to get across the concept using just the word
          "simple":

          http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html

          Regards,

          Tony.

          --
          Tony Byrne
        • David H.
          ... There is a quote that I usually use when confronted with that: Perfection is achieved, not when there is nothing left to add, but when there is nothing
          Message 4 of 22 , Jun 1 4:01 AM
          • 0 Attachment
            > But worse than merely being tuatologous, to me it encourages
            > missinterpretation of "simple" as easiest/quickest/most expedient and
            > thus is not a phrase I would ever use myself to convey what I mean by
            > "simplest".
            >
            There is a quote that I usually use when confronted with that:

            "Perfection is achieved, not when there is nothing left to add, but
            when there is nothing left to remove". -- Antoine de Saint-Exupery

            And I think that is very close to what simple is. Simple, to me, is
            always the most complicated thing to achieve.
          • Ron Jeffries
            ... I love the quote, and have it as one of my sigs. ... I don t find that to be the case. I ve always been fairly good at thinking of simple ways to do
            Message 5 of 22 , Jun 1 4:13 AM
            • 0 Attachment
              On Thursday, June 1, 2006, at 7:01:08 AM, David H. wrote:

              >> But worse than merely being tuatologous, to me it encourages
              >> missinterpretation of "simple" as easiest/quickest/most expedient and
              >> thus is not a phrase I would ever use myself to convey what I mean by
              >> "simplest".
              >>
              > There is a quote that I usually use when confronted with that:

              > "Perfection is achieved, not when there is nothing left to add, but
              > when there is nothing left to remove". -- Antoine de Saint-Exupery

              I love the quote, and have it as one of my sigs.

              > And I think that is very close to what simple is. Simple, to me, is
              > always the most complicated thing to achieve.

              I don't find that to be the case. I've always been fairly good at
              thinking of simple ways to do things, and always been fairly bad at
              getting complex solutions right. Since I started focusing on "the
              simplest thing", things have just gotten better and better for me.

              Ron Jeffries
              www.XProgramming.com
              You do ill if you praise, but worse if you censure,
              what you do not understand. --Leonardo da Vinci
            • Phlip
              ... Pass a test by any means necessary. Clone an entire class and change one line, if that s the most expedient way. If you can t find a simple way to pass the
              Message 6 of 22 , Jun 1 4:52 AM
              • 0 Attachment
                Paul Campbell wrote:

                > Heres a question for the house: what does "simplest thing that could
                > possibly work" mean over and above just "simplest thing" ?. All it
                > seems to do is exclude things which dont work, and what is the point
                > of that in a TDD world ?

                Pass a test by any means necessary. Clone an entire class and change
                one line, if that's the most expedient way.

                If you can't find a simple way to pass the test, step back from the
                situation and look at it agan. Maybe you can sandbox and learn things,
                or maybe you can write a narrower and simpler test.

                After the test passes, you are free to refactor. Now simple means
                "elegant". Perform Extract Class Refactor on your two classes, to
                produce a new base class or delegate class.

                You can also pass a test by lying - by returning a hard-coded value,
                or some such. You fix that by writing enough test cases to force out
                the lie. And that provides cross-coverage.

                --
                Phlip
                http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
              • Ron Jeffries
                ... These are neat techniques and I use and recommend them all. In the present lack of context, I d be concerned that they all seem crazy. Ron Jeffries
                Message 7 of 22 , Jun 1 5:44 AM
                • 0 Attachment
                  On Thursday, June 1, 2006, at 7:52:26 AM, Phlip wrote:

                  > Paul Campbell wrote:

                  >> Heres a question for the house: what does "simplest thing that could
                  >> possibly work" mean over and above just "simplest thing" ?. All it
                  >> seems to do is exclude things which dont work, and what is the point
                  >> of that in a TDD world ?

                  > Pass a test by any means necessary. Clone an entire class and change
                  > one line, if that's the most expedient way.

                  > If you can't find a simple way to pass the test, step back from the
                  > situation and look at it agan. Maybe you can sandbox and learn things,
                  > or maybe you can write a narrower and simpler test.

                  > After the test passes, you are free to refactor. Now simple means
                  > "elegant". Perform Extract Class Refactor on your two classes, to
                  > produce a new base class or delegate class.

                  > You can also pass a test by lying - by returning a hard-coded value,
                  > or some such. You fix that by writing enough test cases to force out
                  > the lie. And that provides cross-coverage.

                  These are neat techniques and I use and recommend them all. In the
                  present lack of context, I'd be concerned that they all seem crazy.

                  Ron Jeffries
                  www.XProgramming.com
                  This is how I develop software.
                  Take the parts that make sense to you.
                  Ignore the rest.
                • Paul Campbell
                  ... But that base is covered by simplest on its own - the clause that could possibly work doesnt provide any further hint that expediency is not what is
                  Message 8 of 22 , Jun 1 8:45 AM
                  • 0 Attachment
                    --- In extremeprogramming@yahoogroups.com, Phlip <phlip2005@...> wrote:
                    >
                    > Paul Campbell wrote:
                    >
                    > > Heres a question for the house: what does "simplest thing that could
                    > > possibly work" mean over and above just "simplest thing" ?. All it
                    > > seems to do is exclude things which dont work, and what is the point
                    > > of that in a TDD world ?
                    >
                    > Pass a test by any means necessary. Clone an entire class and change
                    > one line, if that's the most expedient way.

                    But that base is covered by "simplest" on its own - the clause "that
                    could possibly work" doesnt provide any further hint that expediency
                    is not what is being sought.

                    Paul.
                  • Paul Campbell
                    ... I still maintain that the works bit is a strong enough axiomatic constraint for all software dev that it doesnt need to be restated. ... To me it sounds
                    Message 9 of 22 , Jun 1 8:57 AM
                    • 0 Attachment
                      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                      <ronjeffries@...> wrote:
                      >
                      > On Thursday, June 1, 2006, at 5:35:41 AM, Paul Campbell wrote:
                      >
                      > > Heres a question for the house: what does "simplest thing that could
                      > > possibly work" mean over and above just "simplest thing" ?. All it
                      > > seems to do is exclude things which dont work, and what is the point
                      > > of that in a TDD world ?.
                      >
                      > If it couldn't possibly work, then one might not want to start out
                      > in that direction.

                      I still maintain that the "works" bit is a strong enough axiomatic
                      constraint for all software dev that it doesnt need to be restated.

                      >
                      > Kent Beck used to ask "what is the simplest thing that could
                      > possibly work," to help people get out of analysis paralysis and do
                      > something.
                      >
                      > I began to say "/Do/ the simplest thing that could possibly work,"
                      > for two reasons. First, the power of the idea is to do something
                      > simple enough to get started with, and second, I find it to be a
                      > strong move to start with something really simple, because often it
                      > works just fine.
                      >
                      > > But worse than merely being tuatologous, to me it encourages
                      > > missinterpretation of "simple" as easiest/quickest/most expedient and
                      > > thus is not a phrase I would ever use myself to convey what I mean by
                      > > "simplest".
                      >
                      > I can see how "simplest thing" could be misinterpreted in those
                      > ways, but not why "could possibly work" would make it worse as you
                      > seem to suggest.

                      To me it sounds alot more absolute. Even missing out "possibly" makes
                      it alot better i.e. "simplest thing that works". When I read the
                      original phrase I get a vibe that the "possibly/possible" applies to
                      "simple" as well as "works" and thus in some sense reads as "absolutey
                      the simplest possible thing which works" which is too strong, too hard
                      edged and absolute. Maybe its just me :-).

                      Paul.
                    • Phlip
                      ... Do the simplest thing that could possibly work , at the macro scale, is about fitting features to technology. For example, I know a shop that implemented
                      Message 10 of 22 , Jun 1 9:16 AM
                      • 0 Attachment
                        Paul Campbell wrote:

                        > > Pass a test by any means necessary. Clone an entire class and change
                        > > one line, if that's the most expedient way.
                        >
                        > But that base is covered by "simplest" on its own - the clause "that
                        > could possibly work" doesnt provide any further hint that expediency
                        > is not what is being sought.

                        "Do the simplest thing that could possibly work", at the macro scale,
                        is about fitting features to technology. For example, I know a shop
                        that implemented their own plumbing layer, and is now spending a lot
                        of time researching CORBA. Time to transfer out one simplicity for
                        another.

                        "Do the simplest thing that could possibly work", at the micro scale
                        means different things at different times. While the bar is red, the
                        rules are different.

                        --
                        Phlip
                        http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
                      • Ron Jeffries
                        ... Your privilege. The simplest thing, however, usually won t work. We wouldn t want to suggest that. So the question is, how simple. My answer is: the first
                        Message 11 of 22 , Jun 1 10:24 AM
                        • 0 Attachment
                          On Thursday, June 1, 2006, at 11:57:23 AM, Paul Campbell wrote:

                          >> If it couldn't possibly work, then one might not want to start out
                          >> in that direction.

                          > I still maintain that the "works" bit is a strong enough axiomatic
                          > constraint for all software dev that it doesnt need to be restated.

                          Your privilege. The simplest thing, however, usually won't work. We
                          wouldn't want to suggest that. So the question is, how simple. My
                          answer is: the first simple thing that you aren't sure won't work.

                          Ron Jeffries
                          www.XProgramming.com
                          The main reason that testing at the end of a development cycle finds
                          problems is not that problems were put in near the end, it is that
                          testing was put off until then.
                        • Ron Jeffries
                          ... Always a possibility, I suppose, however unlikely. It seems important to me to find the least non-stupid idea. The simplest thing is probably stupid,
                          Message 12 of 22 , Jun 1 10:28 AM
                          • 0 Attachment
                            On Thursday, June 1, 2006, at 11:57:23 AM, Paul Campbell wrote:

                            >> I can see how "simplest thing" could be misinterpreted in those
                            >> ways, but not why "could possibly work" would make it worse as you
                            >> seem to suggest.

                            > To me it sounds alot more absolute. Even missing out "possibly" makes
                            > it alot better i.e. "simplest thing that works". When I read the
                            > original phrase I get a vibe that the "possibly/possible" applies to
                            > "simple" as well as "works" and thus in some sense reads as "absolutey
                            > the simplest possible thing which works" which is too strong, too hard
                            > edged and absolute. Maybe its just me :-).

                            Always a possibility, I suppose, however unlikely.

                            It seems important to me to find the "least" non-stupid idea. The
                            simplest thing is probably stupid, because it won't work. Other
                            simple things need to be selected among. I like to focus on the
                            simplest one that I can't kick out on the basis of its not working.

                            Ron Jeffries
                            www.XProgramming.com
                            There is no art without intention. -- Duke Ellington
                          • Andrew McDonagh
                            ... Philps set of Simplest ways of making a test pass then refactoring the simple code into well designed code are great, I ve used the same kind of set for
                            Message 13 of 22 , Jun 1 3:18 PM
                            • 0 Attachment
                              Paul Campbell wrote:
                              > Heres a question for the house: what does "simplest thing that could
                              > possibly work" mean over and above just "simplest thing" ?. All it
                              > seems to do is exclude things which dont work, and what is the point
                              > of that in a TDD world ?.
                              >
                              > But worse than merely being tuatologous, to me it encourages
                              > missinterpretation of "simple" as easiest/quickest/most expedient and
                              > thus is not a phrase I would ever use myself to convey what I mean by
                              > "simplest".
                              >
                              > Paul.
                              >
                              >
                              Philps set of 'Simplest ways of making a test pass then refactoring the
                              simple code into well designed code' are great, I've used the same kind
                              of set for a number of years now and i would encourage anyone new to TDD
                              to use them.

                              That said, I think its worth adding what for me 'Simplest thing...' does
                              NOT mean.

                              It does NOT mean being lazy or ignoring the techniques, designs,
                              pit-falls we have already learned.

                              Yet this is often the first thing I see people doing in the name of
                              DTSTTCPW.

                              One example i saw the other year was when a pair decided that creating a
                              Singleton was the 'Simplest thing...'. Sure it was a simple solution to
                              their problem. It allowed them to quickly speed through the story, as
                              they didn't need to modify the current design, they could simply invoke
                              the getInstance() method wherever and whenever they liked - great!

                              Errr no, not really, it created the start of a mess, because an up
                              coming iteration required that we'd need to create two instances of the
                              class.

                              Whilst working on this later iteration, one of the original pair was
                              also working on the story which required us to create a second instance
                              of the class. Again, the 'Simplest thing...' misconception kicked in
                              with them. They didn't look at the current singleton design and think
                              'Hmm we should refactor this singleton away'. No, they 'Simply' added a
                              setInstance() method to the Singleton.

                              So now we had a singleton that actually wasn't a singleton - all because
                              of they'd taken the 'Simplest thing...' too literally.

                              They even joked that they'd '..had to create a Doubleton' - its humor
                              was lost on the delay it caused when we had to change the design.

                              I'd agreed whole heartedly therefore that Simplest can often be mistaken
                              (whether deliberately or not) as easiest/quickest/most expedient.

                              Andrew
                            • Walter Prins
                              Hello Andew, Yes. To me the work part of could possibly works implies that you need to take a brief step back and ensure that whatever you come up with
                              Message 14 of 22 , Jun 1 4:22 PM
                              • 0 Attachment
                                Hello Andew,

                                Yes. To me the "work" part of "could possibly works" implies that you
                                need to take a brief step back and ensure that whatever you come up with
                                must be able to at least satisfy not just the immediate need (that is,
                                to get to green for this story), but you must at least be able to also
                                foresee some simple-ish path forward for the other bits you're aware
                                that will happen or will be needed (as imperfect and incomplete as that
                                understanding might be at that moment.) At the very least, whatever
                                you do now in the name of simplicity must not obviously cause complexity
                                and trouble come the next story.

                                So, considering your Singleton example: for this reason, I would
                                probably have rejected the whole idea of using a singleton there as I
                                would've seen that it probably would not work (or, at least, not in a
                                simple manner) when we got to some of the other stories that were in the
                                pipeline.

                                It seems to me that interpreting TSTTCPW in this way thus helps avoid (I
                                hope/I think) the oversimplistic thinking that you refer to. Thoughts?

                                Regards,

                                Walter

                                Andrew McDonagh wrote:
                                >
                                > I'd agreed whole heartedly therefore that Simplest can often be mistaken
                                > (whether deliberately or not) as easiest/quickest/most expedient.
                                >
                                >
                              • Anthony Kaufman
                                I discovered XP about a year and a half ago and have been migrating my thinking in that direction since then so I m by no means an expert. I have to confess
                                Message 15 of 22 , Jun 8 12:31 PM
                                • 0 Attachment
                                  I discovered XP about a year and a half ago and have been migrating my
                                  thinking in that direction since then so I'm by no means an expert. I have
                                  to confess that I did initially take the simplest thing to mean the easiest
                                  thing.

                                  I'll go back to Kent's list in light of Andrew's issue.
                                  1. Runs all the tests - The Singleton obviously ran all tests, so did the
                                  Doubleton.
                                  2. Contains no duplication - Guessing they both still pass this test as
                                  well.
                                  3. Expresses all the code's design ideas - The Singleton totally could have
                                  done this but I don't know what the code actually looked like. However, the
                                  Doubleton breaks down here. It sounds like it doesn't do a great job of
                                  making the design clear.
                                  4. Minimizes entities (classes, methods, ...) - Yeah, sounds like they both
                                  achieve this.

                                  The question in my mind now is:
                                  Does the simplest design state that you should take into account stories to
                                  come when constructing your design for the story right now?

                                  If down the road you'll need a plane, but this story only wants something
                                  that'll drive down the runway, should you construct landing gear and some
                                  fuselage or just a build a moped?

                                  "Right" kindof depends on how things turn out. If you end up constructing a
                                  plane as was planned, you'll be pleased. Your extra effort to construct
                                  landing gear and fuselage was worth it. However, if all you ever need is
                                  something that'll drive down a runway, or if your planned "flying" stories
                                  are scraped and replaced with "drive down the road" stories, you'll have
                                  wasted time. And until you implement the flying stories you have this weird
                                  plane shaped vehicle teetering around. Wasn't one of the goals of XP to
                                  always have an ideal system at the end of an iteration?

                                  Anthony

                                  On 6/1/06, Walter Prins <wprins@...> wrote:
                                  >
                                  > Hello Andew,
                                  >
                                  > Yes. To me the "work" part of "could possibly works" implies that you
                                  > need to take a brief step back and ensure that whatever you come up with
                                  > must be able to at least satisfy not just the immediate need (that is,
                                  > to get to green for this story), but you must at least be able to also
                                  > foresee some simple-ish path forward for the other bits you're aware
                                  > that will happen or will be needed (as imperfect and incomplete as that
                                  > understanding might be at that moment.) At the very least, whatever
                                  > you do now in the name of simplicity must not obviously cause complexity
                                  > and trouble come the next story.
                                  >
                                  > So, considering your Singleton example: for this reason, I would
                                  > probably have rejected the whole idea of using a singleton there as I
                                  > would've seen that it probably would not work (or, at least, not in a
                                  > simple manner) when we got to some of the other stories that were in the
                                  > pipeline.
                                  >
                                  > It seems to me that interpreting TSTTCPW in this way thus helps avoid (I
                                  > hope/I think) the oversimplistic thinking that you refer to. Thoughts?
                                  >
                                  > Regards,
                                  >
                                  > Walter
                                  >
                                  > Andrew McDonagh wrote:
                                  > >
                                  > > I'd agreed whole heartedly therefore that Simplest can often be mistaken
                                  > > (whether deliberately or not) as easiest/quickest/most expedient.
                                  > >
                                  > >
                                  >
                                  >
                                  > To Post a message, send it to: extremeprogramming@...
                                  >
                                  > To Unsubscribe, send a blank message to:
                                  > extremeprogramming-unsubscribe@...
                                  >
                                  > ad-free courtesy of objectmentor.com
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >


                                  [Non-text portions of this message have been removed]
                                • Ron Jeffries
                                  ... No. It should run the tests, contain no duplication, express all the design ideas presently in it, and minize stuff ... ... A really good moped. ... Except
                                  Message 16 of 22 , Jun 8 1:23 PM
                                  • 0 Attachment
                                    On Thursday, June 8, 2006, at 3:31:05 PM, Anthony Kaufman wrote:

                                    > Does the simplest design state that you should take into account stories to
                                    > come when constructing your design for the story right now?

                                    No. It should run the tests, contain no duplication, express all the
                                    design ideas presently in it, and minize stuff ...

                                    > If down the road you'll need a plane, but this story only wants something
                                    > that'll drive down the runway, should you construct landing gear and some
                                    > fuselage or just a build a moped?

                                    A really good moped.

                                    > "Right" kindof depends on how things turn out. If you end up constructing a
                                    > plane as was planned, you'll be pleased. Your extra effort to construct
                                    > landing gear and fuselage was worth it.

                                    Except that it was waste investment doing it when all you were doing
                                    was cruising around on the runway ... better to save the time and
                                    money until later.

                                    > However, if all you ever need is
                                    > something that'll drive down a runway, or if your planned "flying" stories
                                    > are scraped and replaced with "drive down the road" stories, you'll have
                                    > wasted time. And until you implement the flying stories you have this weird
                                    > plane shaped vehicle teetering around. Wasn't one of the goals of XP to
                                    > always have an ideal system at the end of an iteration?

                                    Ideal for what it then does. Not ideal for what it will someday do.
                                    The rules of simple design make it ideal for what it has to do next.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    The work teaches us. -- Richard Gabriel
                                  • geoffrey_slinker
                                    ... wrote: ... Please help me out a bit. When I read these types of posts I wonder if the scenario in question is always contrived
                                    Message 17 of 22 , Jun 8 3:41 PM
                                    • 0 Attachment
                                      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                      <ronjeffries@...> wrote:
                                      <snip>
                                      > Ideal for what it then does. Not ideal for what it will someday do.
                                      > The rules of simple design make it ideal for what it has to do next.
                                      >

                                      Please help me out a bit.

                                      When I read these types of posts I wonder if the scenario in question
                                      is always contrived with this idea that "we MAY need X, Y, or Z". It
                                      almost sounds like all projects are small and no one incrementally
                                      builds large systems, and no one knows the real customer needs.

                                      Suppose the requirement says, "We need a vehicle that can go down a
                                      runway". Firstly, the term runway is typically in the domain of
                                      aeronautics and so one could ask, "Do you mean you need an airplane,
                                      or do you need a firetruck, or do you need a baggage tractor?" But
                                      maybe I am more familiar with the fashion industry and so I give you
                                      a supermodel on roller blades.

                                      These scenarios are often presented in such a way so that there are
                                      no communication paths available to the developer.

                                      For example, suppose the "product" to be built is an airplane. The
                                      scenario is as if the Project Manager divied up the tasks to
                                      different development teams that can not talk to each other and that
                                      the big picture is only given on a need to know basis. It is like the
                                      PM told one group, "Build me something that can roll down a runway"
                                      and he told another group to "build me something that can seat 8
                                      passengers" and yet a third group he told "build me something that
                                      can make things fly".

                                      There should be a big picture. You should know what is required. If
                                      something comes up that you think may be needed then tell someone so
                                      that it can be determined if something was overlooked. If it is not
                                      an oversight then don't make it. Clearly simple design, regression
                                      tests, properly defined domain, etc., can make the system easy to
                                      extend and from my experience software is usually extended.

                                      Many times I have heard, "xp doesn't mean check your brain at the
                                      door". Making a big picture doesn't mean do BDUF. Understanding your
                                      customer's requirements doesn't mean do BDUF. There is a planning
                                      game to determing the product. Then this product (which is the big
                                      picture) is divided up and releases and iterations are defined and
                                      the product is delivered incrementally.

                                      If you need a tractor, a plane, or a supermodel on roller blades, it
                                      should be known by someone somewhere somehow.

                                      I don't know, but it seems like I am missing something, or
                                      misunderstanding something...

                                      Geoff
                                    • Andrew McDonagh
                                      ... You are right, there is a big picture, there has been a release planning session and iteration sessions too. That unfortunately is not the issue. Its
                                      Message 18 of 22 , Jun 8 4:32 PM
                                      • 0 Attachment
                                        geoffrey_slinker wrote:
                                        >
                                        > --- In extremeprogramm
                                        >
                                        > If you need a tractor, a plane, or a supermodel on roller blades, it
                                        > should be known by someone somewhere somehow.
                                        >
                                        > I don't know, but it seems like I am missing something, or
                                        > misunderstanding something...
                                        >
                                        > Geoff


                                        You are right, there is a big picture, there has been a release planning
                                        session and iteration sessions too.

                                        That unfortunately is not the issue. Its blind adherence to Do The
                                        Simplest Thing for the CURRENT iteration.

                                        When ever we create software, there are numerous ways we could do it -
                                        some are more open to change than others. But this flexibility is often
                                        not as Simple as the ridged design. And its the choosing to do the more
                                        ridged design because its Simple that causes the problems.
                                      • yahoogroups@jhrothjr.com
                                        From: Andrew McDonagh To: extremeprogramming@yahoogroups.com
                                        Message 19 of 22 , Jun 8 5:01 PM
                                        • 0 Attachment
                                          From: "Andrew McDonagh"
                                          <yahoogroups.at.andrewmcdonagh.f2s.com@...>
                                          To: "extremeprogramming@yahoogroups.com"
                                          <extremeprogramming.at.yahoogroups.com@...>
                                          Sent: Thursday, June 08, 2006 5:32 PM
                                          Subject: Re: [XP] meaning of "could possibly work" clause


                                          > geoffrey_slinker wrote:
                                          > >
                                          > > --- In extremeprogramm
                                          > >
                                          > > If you need a tractor, a plane, or a supermodel on roller blades, it
                                          > > should be known by someone somewhere somehow.
                                          > >
                                          > > I don't know, but it seems like I am missing something, or
                                          > > misunderstanding something...
                                          > >
                                          > > Geoff
                                          >
                                          >
                                          > You are right, there is a big picture, there has been a release planning
                                          > session and iteration sessions too.
                                          >
                                          > That unfortunately is not the issue. Its blind adherence to Do The
                                          > Simplest Thing for the CURRENT iteration.
                                          >
                                          > When ever we create software, there are numerous ways we could do it -
                                          > some are more open to change than others. But this flexibility is often
                                          > not as Simple as the ridged design. And its the choosing to do the more
                                          > ridged design because its Simple that causes the problems.

                                          Simplicity satisfies the _real_ requirements of the domain without
                                          a lot of additional cruft, and without throwing all those embarrasing
                                          complexities over the fence for someone else to deal with.

                                          If you tell me that this code, once written, is never, ever going to
                                          be maintained, I'm going to look at you with extreme skepticism.
                                          In fact, if you can't give me a good reason why I should think that,
                                          I'll look at you as either very naive or as lying to me in order to
                                          manipulate me into not doing those things that I know make code
                                          maintainable.

                                          It doesn't matter to me how simple it looks, if it can't be maintained
                                          it's not simple.

                                          John Roth

                                          What makes a design rigid?


                                          >
                                          >
                                          >
                                        • Ron Jeffries
                                          ... I m not sure how to do a rigid design. I am sure that if the cod runs all the tests, has no duplication, expresses all the design ideas so far, and
                                          Message 20 of 22 , Jun 8 6:11 PM
                                          • 0 Attachment
                                            On Thursday, June 8, 2006, at 7:32:18 PM, Andrew McDonagh wrote:

                                            > You are right, there is a big picture, there has been a release planning
                                            > session and iteration sessions too.

                                            > That unfortunately is not the issue. Its blind adherence to Do The
                                            > Simplest Thing for the CURRENT iteration.

                                            > When ever we create software, there are numerous ways we could do it -
                                            > some are more open to change than others. But this flexibility is often
                                            > not as Simple as the ridged design. And its the choosing to do the more
                                            > ridged design because its Simple that causes the problems.

                                            I'm not sure how to do a rigid design. I am sure that if the cod
                                            runs all the tests, has no duplication, expresses all the design
                                            ideas so far, and minimizes entities, it's bloody hard to also make
                                            it difficult to change.

                                            Yes, that is a challenge: I'd like to see some code that meets the
                                            Beck rules and is hard to change.

                                            Ron Jeffries
                                            www.XProgramming.com
                                            We know less about the project today than at any time in the future.
                                            -- Chet Hendrickson
                                            You mean today is the dumbest day of the rest of my life?
                                            -- Ron Jeffries
                                          • Ron Jeffries
                                            ... I shall do my best. (Ben Stein) ... I m not assuming that we don t know, and I m not assuming that things may change. I assert that at any given moment, if
                                            Message 21 of 22 , Jun 8 6:21 PM
                                            • 0 Attachment
                                              On Thursday, June 8, 2006, at 6:41:51 PM, geoffrey_slinker wrote:

                                              >> Ideal for what it then does. Not ideal for what it will someday do.
                                              >> The rules of simple design make it ideal for what it has to do next.
                                              >>

                                              > Please help me out a bit.

                                              I shall do my best. (Ben Stein)

                                              > When I read these types of posts I wonder if the scenario in question
                                              > is always contrived with this idea that "we MAY need X, Y, or Z". It
                                              > almost sounds like all projects are small and no one incrementally
                                              > builds large systems, and no one knows the real customer needs.

                                              I'm not assuming that we don't know, and I'm not assuming that
                                              things may change. I assert that at any given moment, if we're
                                              implementing feature by feature, the best way for the design to be
                                              is exactly right for the features then implemented, not exactly
                                              right for some future state.

                                              We might wish to explore what would have to be true for that
                                              assertion to be true, depending on where your thoughts, and those of
                                              others, go next.

                                              > Suppose the requirement says, "We need a vehicle that can go down a
                                              > runway". Firstly, the term runway is typically in the domain of
                                              > aeronautics and so one could ask, "Do you mean you need an airplane,
                                              > or do you need a firetruck, or do you need a baggage tractor?" But
                                              > maybe I am more familiar with the fashion industry and so I give you
                                              > a supermodel on roller blades.

                                              It has to pass the customer's tests. The example is amusing but
                                              perhaps too intentionally obtuse.

                                              > These scenarios are often presented in such a way so that there are
                                              > no communication paths available to the developer.

                                              Agile software development /requires/ a communication path to the
                                              developer. Everything I've been talking about so far assumes that
                                              context. On the other hand, without such a path, even if you're
                                              doing waterfall, you don't know whether they want a plane or a
                                              supermodel on wheels.

                                              > For example, suppose the "product" to be built is an airplane. The
                                              > scenario is as if the Project Manager divied up the tasks to
                                              > different development teams that can not talk to each other and that
                                              > the big picture is only given on a need to know basis. It is like the
                                              > PM told one group, "Build me something that can roll down a runway"
                                              > and he told another group to "build me something that can seat 8
                                              > passengers" and yet a third group he told "build me something that
                                              > can make things fly".

                                              Suppose the product is software. We're talking about software and
                                              how to do software. Airplanes are not software. The example won't
                                              fly.

                                              > There should be a big picture. You should know what is required. If
                                              > something comes up that you think may be needed then tell someone so
                                              > that it can be determined if something was overlooked. If it is not
                                              > an oversight then don't make it. Clearly simple design, regression
                                              > tests, properly defined domain, etc., can make the system easy to
                                              > extend and from my experience software is usually extended.

                                              Yes, software is usually extended. Yes, it's good to know where
                                              you're probably going to go.

                                              That emphatically does not imply that you should do extra work now
                                              to prepare for something that is going to happen later.

                                              > Many times I have heard, "xp doesn't mean check your brain at the
                                              > door". Making a big picture doesn't mean do BDUF. Understanding your
                                              > customer's requirements doesn't mean do BDUF. There is a planning
                                              > game to determing the product. Then this product (which is the big
                                              > picture) is divided up and releases and iterations are defined and
                                              > the product is delivered incrementally.

                                              > If you need a tractor, a plane, or a supermodel on roller blades, it
                                              > should be known by someone somewhere somehow.

                                              Sure. It's wonderful to know ...

                                              > I don't know, but it seems like I am missing something, or
                                              > misunderstanding something...

                                              Well, software isn't a tractor, a plane, or even a supermodel on
                                              skates. That could be part of the issue.

                                              The question I was originally answering had to do with whether, at a
                                              given iteration, the design should have in it things preparing for
                                              future iterations. My answer is that, other than being a good design
                                              for the features now in the system, there is no need to put stuff in
                                              for the future. Good design /is/ design for the future: modularity
                                              works.

                                              I don't know at all how to build an airplane by incremental
                                              development with refactoring. I do know a fair amount about how to
                                              build software that way, and I think I can be more helpful talking
                                              about that.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              We cannot solve our problems with the same thinking we used when we created them.
                                              -- Albert Einstein
                                            • geoffrey_slinker
                                              (Sorry, but I made a very thought out reply and it seems to have disappeard...) Thanks for your time and your response. ... Yes! Good design /is/ design for
                                              Message 22 of 22 , Jun 9 8:55 AM
                                              • 0 Attachment
                                                (Sorry, but I made a very thought out reply and it seems to have
                                                disappeard...)

                                                Thanks for your time and your response.

                                                >
                                                > The question I was originally answering had to do with whether, at a
                                                > given iteration, the design should have in it things preparing for
                                                > future iterations. My answer is that, other than being a good design
                                                > for the features now in the system, there is no need to put stuff in
                                                > for the future. Good design /is/ design for the future: modularity
                                                > works.

                                                Yes! Good design /is/ design for the future: modularity works.

                                                XP is the environment in which the developer can apply his skills.
                                                Good design is a skill that can be acquired through lots of study,
                                                experimentation, and application. XP is an excellent environment in
                                                which a developer is trusted and therefor allowed to practice his
                                                profession with excellence.

                                                Thanks,
                                                Geoff
                                              Your message has been successfully submitted and would be delivered to recipients shortly.