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

Simple ain't Easy: Myths and Misunderstandings about Simplicity

Expand Messages
  • Brad Appleton
    I just blogged at length on this subject at http://blog.bradapp.net/ (as well as providing a list of web resources & famous quotations on the subject) and
    Message 1 of 15 , May 30, 2006
    • 0 Attachment
      I just blogged at length on this subject at http://blog.bradapp.net/
      (as well as providing a list of web resources & famous quotations on the
      subject) and would be interested in people's impressions and commentary
      on what I jotted down in my blog-entry.

      Some relevant excerpts ...
      ==========================
      - "Simple is not the same thing as "easy to do/understand."
      - "Simple design" is not the same thing as "simple to develop/deploy."
      - "Simple" is not the same thing as "good enough!"
      - "Simple" is not the same thing as "simplistic!"
      - What is "simple" for one request may not be "simple" for the whole!

      ... The Agile Manifesto defines simplicity as "maximizing the amount of
      work not done." But I think that's a more accurate characterization of
      Lean than of simplicity.

      ... Simplicity involves being able to see the whole from a system's
      thinking perspective while at the same time being able to focus in on
      what is relevant and essential and how it impacts the rest of the
      system. Sustainable simplicity often has to evolve or emerge on it's own
      from a set of simple guiding rules.

      The opposite of simplicity is complexity (as opposed to "hard" or
      "difficult" or "time-consuming" or "labor-intensive") ... Hiding
      complexity isn't the same as removing complexity.

      I think that true simplicity is about minimizing and managing overall
      complexity. For any non-trivial system, simplicity often has less to do
      with the number and kind of different things involved and more to do
      with the number and kind of interdependencies between them. Simplicity
      is less about managing "points" and "things" and more about managing
      rules and relationships.

      When dealing with large or complex systems (like most software, and
      software processes) the number of things (scale) and different types of
      things (diversity) that need to be managed is overwhelming. If we can
      come up with a modicum of modest, simple rules & principles to govern
      our design decisions in ways that helps us minimize and manage
      interdependencies, eliminate constraints, and remove waste, then we are
      on the path to solving the real problem and meeting stakeholder needs in
      a way that is both simple and sustainable.

      --
      Brad Appleton <brad {AT} bradapp.net>
      Agile CM Environments (http://blog.bradapp.net/)
      & Software CM Patterns (www.scmpatterns.com)
      "And miles to go before I sleep" -- Robert Frost
    • Justin T. Sampson
      ... Simple means lots of things, of course; maybe lean is a more descriptive word for what we re talking about. I ve been thinking lately that lean process
      Message 2 of 15 , May 30, 2006
      • 0 Attachment
        Brad Appleton wrote (rearranged a bit):

        > ... The Agile Manifesto defines simplicity as "maximizing the
        > amount of work not done." But I think that's a more accurate
        > characterization of Lean than of simplicity.

        Simple means lots of things, of course; maybe "lean" is a more
        descriptive word for what we're talking about. I've been thinking
        lately that "lean process" and "lean product" really go
        hand-in-hand. Lean is about eliminating waste, so a lean product
        doesn't contain anything that's not of actual value to the user,
        and is designed in such a way as to not cause waste in deployment
        and maintenance. Duplication of code would be an example of
        something that causes waste in maintenance. Repetitive,
        error-prone manual installation steps would be examples of waste
        in deployment.

        > - "Simple is not the same thing as "easy to do/understand."

        Yeah, the distinction between "simple" and "easy" is perhaps the
        most important and easiest to miss.

        > - "Simple design" is not the same thing as "simple to
        > develop/deploy."

        If there's waste in the development or deployment process due to
        the software design, I think we can say the design is not simple,
        or certainly not lean. What else do you mean by "simple to
        develop/deploy"?

        > - "Simple" is not the same thing as "good enough!"

        It does mean that there's nothing in the product that's not of
        real value to the real user, which is how I understand what some
        people here have meant by "good enough"...

        > - "Simple" is not the same thing as "simplistic!"

        Yeah, this is close to the simple/easy distinction as well.

        > - What is "simple" for one request may not be "simple" for the
        > whole!

        Also an example of simple vs. easy, I think. A local optimization
        (easy solution) can be a source of waste in the whole process.

        Cheers,
        Justin
      • Brad Appleton
        Hi Justin! Thanks for the feedback. My responses below ... ... That s what I was thinking. Maximizing work not done seems to be about minimizing effort &
        Message 3 of 15 , May 30, 2006
        • 0 Attachment
          Hi Justin! Thanks for the feedback. My responses below ...

          Justin T. Sampson wrote:
          > Brad Appleton wrote (rearranged a bit):
          >
          > > ... The Agile Manifesto defines simplicity as "maximizing the
          > > amount of work not done." But I think that's a more accurate
          > > characterization of Lean than of simplicity.
          >
          > Simple means lots of things, of course; maybe "lean" is a more
          > descriptive word for what we're talking about.

          That's what I was thinking. Maximizing work not done seems to be about
          minimizing effort & artifacts. I think that's a good thing. I'm thinking
          simple is about minimizing/removing (inter)dependencies, which is
          related but different.

          > I've been thinking lately that "lean process" and "lean product" really go
          > hand-in-hand. Lean is about eliminating waste, so a lean product
          > doesn't contain anything that's not of actual value to the user,
          > and is designed in such a way as to not cause waste in deployment
          > and maintenance. Duplication of code would be an example of
          > something that causes waste in maintenance. Repetitive,
          > error-prone manual installation steps would be examples of waste
          > in deployment.

          So if lean is in part about speed and minimizing time, then at some
          level "lean product" is merely a "derivative" of having a "lean process"?


          > > - "Simple design" is not the same thing as "simple to
          > > develop/deploy."
          >
          > If there's waste in the development or deployment process due to
          > the software design, I think we can say the design is not simple,
          > or certainly not lean. What else do you mean by "simple to
          > develop/deploy"?

          The blog-entry at http://blog.bradapp.net/ actually has a paragraph (or
          three :-) explaining each one of those bullet items. Here it mentions
          possible effort involved to change an existing design so that it is simpler.

          Again, it's really just another variant of "simple versus easy." If a
          legacy system is in place, then what is easiest to develop/deploy may
          really just be a bunch of band-aids that dont solve the real problems
          nor make things any simpler. What truly makes things simpler may involve
          a lot of work to develop and deploy in order to put the simpler design
          into effect to replace the less simple one.

          Think of the effort involved to "refactor" a system that was never
          refactored before and had lots of redundancy and no real "simple/supple"
          design. Suggestions to change it to make it simpler will often be met by
          resistance about how much work it will be to "pay off all that technical
          debt" whose size has been steadily compounding over time.

          > > - "Simple" is not the same thing as "good enough!"
          >
          > It does mean that there's nothing in the product that's not of
          > real value to the real user, which is how I understand what some
          > people here have meant by "good enough"...

          Im thinking of something like TDD and Refactoring where the mantra is
          often something like "red-green-refactor". Only after you hit "green
          bar" and before you have "refactored", someone tries to say "good enough!"

          "Good enough" for now doesnt mean "easy to change" for later. Simple is
          what helps is make it easy to change for later, rather than just easiest
          to do right now.

          --
          Brad Appleton <brad {AT} bradapp.net>
          Agile CM Environments (http://blog.bradapp.net/)
          & Software CM Patterns (www.scmpatterns.com)
          "And miles to go before I sleep" -- Robert Frost
        • Graeme Matthew
          This is extremely interesting ..... Here is my 2 cents Brad said Simple is not the same thing as easy to do/understand. Something can be defined as Simple
          Message 4 of 15 , May 31, 2006
          • 0 Attachment
            This is extremely interesting .....

            Here is my 2 cents

            Brad said "Simple is not the same thing as "easy to do/understand."

            Something can be defined as "Simple" by looking at the the time taken to
            understand something new.

            It is always easy to do something if you understand how to do it, even
            if it is not simple, but because you understand it, it seems simple but
            to others it is complex.

            For example:

            If it takes 5 people on average 3 hours each to understand something,
            thats a long time so it may not be simple, if it takes 5 people on
            average 5 minutes to understand something then I would deem it simple.

            In conclusion simple can be defined as "an agreed upon measurement of
            time to understand something correctly."


            Cheers

            Graeme


            Brad Appleton wrote:
            > Hi Justin! Thanks for the feedback. My responses below ...
            >
            > Justin T. Sampson wrote:
            >
            >> Brad Appleton wrote (rearranged a bit):
            >>
            >> > ... The Agile Manifesto defines simplicity as "maximizing the
            >> > amount of work not done." But I think that's a more accurate
            >> > characterization of Lean than of simplicity.
            >>
            >> Simple means lots of things, of course; maybe "lean" is a more
            >> descriptive word for what we're talking about.
            >>
            >
            > That's what I was thinking. Maximizing work not done seems to be about
            > minimizing effort & artifacts. I think that's a good thing. I'm thinking
            > simple is about minimizing/removing (inter)dependencies, which is
            > related but different.
            >
            >
            >> I've been thinking lately that "lean process" and "lean product" really go
            >> hand-in-hand. Lean is about eliminating waste, so a lean product
            >> doesn't contain anything that's not of actual value to the user,
            >> and is designed in such a way as to not cause waste in deployment
            >> and maintenance. Duplication of code would be an example of
            >> something that causes waste in maintenance. Repetitive,
            >> error-prone manual installation steps would be examples of waste
            >> in deployment.
            >>
            >
            > So if lean is in part about speed and minimizing time, then at some
            > level "lean product" is merely a "derivative" of having a "lean process"?
            >
            >
            >
            >> > - "Simple design" is not the same thing as "simple to
            >> > develop/deploy."
            >>
            >> If there's waste in the development or deployment process due to
            >> the software design, I think we can say the design is not simple,
            >> or certainly not lean. What else do you mean by "simple to
            >> develop/deploy"?
            >>
            >
            > The blog-entry at http://blog.bradapp.net/ actually has a paragraph (or
            > three :-) explaining each one of those bullet items. Here it mentions
            > possible effort involved to change an existing design so that it is simpler.
            >
            > Again, it's really just another variant of "simple versus easy." If a
            > legacy system is in place, then what is easiest to develop/deploy may
            > really just be a bunch of band-aids that dont solve the real problems
            > nor make things any simpler. What truly makes things simpler may involve
            > a lot of work to develop and deploy in order to put the simpler design
            > into effect to replace the less simple one.
            >
            > Think of the effort involved to "refactor" a system that was never
            > refactored before and had lots of redundancy and no real "simple/supple"
            > design. Suggestions to change it to make it simpler will often be met by
            > resistance about how much work it will be to "pay off all that technical
            > debt" whose size has been steadily compounding over time.
            >
            >
            >> > - "Simple" is not the same thing as "good enough!"
            >>
            >> It does mean that there's nothing in the product that's not of
            >> real value to the real user, which is how I understand what some
            >> people here have meant by "good enough"...
            >>
            >
            > Im thinking of something like TDD and Refactoring where the mantra is
            > often something like "red-green-refactor". Only after you hit "green
            > bar" and before you have "refactored", someone tries to say "good enough!"
            >
            > "Good enough" for now doesnt mean "easy to change" for later. Simple is
            > what helps is make it easy to change for later, rather than just easiest
            > to do right now.
            >
            >
          • Brad Appleton
            Hi Graeme! Thanks for the response. ... So, in your mind, simple is primarily concerned with clarity/comprehensibility, is that right? I m thinking that a
            Message 5 of 15 , May 31, 2006
            • 0 Attachment
              Hi Graeme! Thanks for the response.

              On 5/31/06, Graeme Matthew <scrum@...> wrote:
              This is extremely interesting .....

              Here is my 2 cents

              Brad said "Simple is not the same thing as "easy to do/understand."

              Something can be defined as "Simple" by looking at the the time taken to
              understand something new. [...] In conclusion simple can be defined as "an agreed upon measurement of time to understand something correctly."
               
              So, in your mind, "simple" is primarily concerned with clarity/comprehensibility, is that right?
               
              I'm thinking that a solution can be easy to understand, but still have more than its fair share of undesirable interdependencies. And that often times the "simpler" solution requires a change in one's frame-of-mind in thinking about the problem. It may be harder/more time-consuming to make that mental shift, and it often involves taking a broader perspective. But once we do that, the pieces may seem more apparent and to more naturally fall into place.
               
              Often we are all starting from different mind-sets, so the ease (and time) for us to comprehend something new will be largely subjective, and even culturally and contextually sensitive.
               
              But if simple is about really about minimizing and managing interdependencies (rules & relationships among entities), that would be more likely to be objective (I think).
               
              Relative clarity/comprehension may be a good indicator if all concerned are starting from the same common foundation or "baseline", or if we're starting from scratch without an existing solution already in place that needs to be tweaked or refactored.
               
              I wonder if there is a difference between the clarity/comprehensibility of a design versus of its description/explanation?

              --
              Brad Appleton <brad AT bradapp.net >
                Agile CM Environments (http://blog.bradapp.net/)
                & Software CM Patterns (http://www.scmpatterns.com/)
              "And miles to go before I sleep." -- Robert Frost
            • Ron Jeffries
              ... I d think that comprehensibility is likely a good indicator of simplicity. You suggest that something can be easy to understand yet still have undesirable
              Message 6 of 15 , May 31, 2006
              • 0 Attachment
                On Wednesday, May 31, 2006, at 3:10:27 PM, Brad Appleton wrote:

                >> Something can be defined as "Simple" by looking at the the time taken to
                >> understand something new. [...] In conclusion simple can be defined as "an
                >> agreed upon measurement of time to understand something correctly."
                >>

                > So, in your mind, "simple" is primarily concerned with
                > clarity/comprehensibility, is that right?

                > I'm thinking that a solution can be easy to understand, but still have more
                > than its fair share of undesirable interdependencies. And that often times
                > the "simpler" solution requires a change in one's frame-of-mind in thinking
                > about the problem. It may be harder/more time-consuming to make that mental
                > shift, and it often involves taking a broader perspective. But once we do
                > that, the pieces may seem more apparent and to more naturally fall into
                > place.

                > Often we are all starting from different mind-sets, so the ease (and
                > time) for us to comprehend something new will be largely subjective, and
                > even culturally and contextually sensitive.

                > But if simple is about really about minimizing and managing
                > interdependencies (rules & relationships among entities), that would be more
                > likely to be objective (I think).

                > Relative clarity/comprehension may be a good indicator if all concerned are
                > starting from the same common foundation or "baseline", or if we're starting
                > from scratch without an existing solution already in place that needs to be
                > tweaked or refactored.

                > I wonder if there is a difference between the clarity/comprehensibility of a
                > design versus of its description/explanation?

                I'd think that comprehensibility is likely a good indicator of
                simplicity. You suggest that something can be easy to understand yet
                still have undesirable interdependencies. I'd want to understand
                that notion better than I do now ... because I'd think those
                interdependencies would need to be understood and would therefore be
                making the thing harder to comprehend.

                Certainly it is possible to describe a simple thing poorly. I do it
                all the time. ;-> But whether it's possible to have a simple thing
                which simply /cannot/ be described simply ... I have my doubts about
                that.

                Ron Jeffries
                www.XProgramming.com
                Adapt, improvise, overcome.
                --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
              • scrum@contrado.com.au
                Yes I would say that it primarily revolves around clarity / comprehensibility but also the ability to quickly complete a given task with minimal knowledge. For
                Message 7 of 15 , May 31, 2006
                • 0 Attachment
                  Yes I would say that it primarily revolves around clarity /
                  comprehensibility but also the ability to quickly complete a given task
                  with minimal knowledge. For an object (design, diagram, document, code,
                  anything really) to be deemed simple it has to first be understood.

                  Simple is always about perception as we are all different, so we can
                  call this Simple from an Audience perspective.

                  I have an insurance application screen that simply has 6 fields and a
                  calculate button. The user enters the data for the 6 fields and clicks
                  on calculate and it performs a complex cover calculation and displays
                  the result. The insurance user (audience group 1) would deem this
                  simple, they have the insurance knowledge, the fields are labelled, it
                  takes 1 minute to understand and in an instant they have completed the
                  cover calculation i.e. simple usage.

                  Now the developers (audience group 2) look at the screen and go jeez
                  that took 100 hours of complex development to get that calc working.
                  i.e. Complex implementation.

                  I also think that simple may relate to something singluar. I believe
                  anything with interdependencies where a change to one affects the other
                  cannot be deemed simple, and if a change to one did not cause a change
                  to the other then it cannot be an interdependency it is simply a loose
                  link.

                  This is getting a bit out there !


                  Cheers

                  Graeme








                  >
                  > Hi Graeme! Thanks for the response.
                  >
                  > On 5/31/06, Graeme Matthew <scrum@...> wrote:
                  > >
                  > > This is extremely interesting .....
                  > >
                  > > Here is my 2 cents
                  > >
                  > > Brad said "Simple is not the same thing as "easy to do/understand."
                  > >
                  > > Something can be defined as "Simple" by looking at the the time taken to
                  > > understand something new. [...] In conclusion simple can be defined
                  as "an
                  > > agreed upon measurement of time to understand something correctly."
                  > >
                  >
                  > So, in your mind, "simple" is primarily concerned with
                  > clarity/comprehensibility, is that right?
                  >
                  > I'm thinking that a solution can be easy to understand, but still have
                  more
                  > than its fair share of undesirable interdependencies. And that often times
                  > the "simpler" solution requires a change in one's frame-of-mind in
                  thinking
                  > about the problem. It may be harder/more time-consuming to make that
                  mental
                  > shift, and it often involves taking a broader perspective. But once we do
                  > that, the pieces may seem more apparent and to more naturally fall into
                  > place.
                  >
                  > Often we are all starting from different mind-sets, so the ease (and
                  > time) for us to comprehend something new will be largely subjective, and
                  > even culturally and contextually sensitive.
                  >
                  > But if simple is about really about minimizing and managing
                  > interdependencies (rules & relationships among entities), that would
                  be more
                  > likely to be objective (I think).
                  >
                  > Relative clarity/comprehension may be a good indicator if all
                  concerned are
                  > starting from the same common foundation or "baseline", or if we're
                  starting
                  > from scratch without an existing solution already in place that needs
                  to be
                  > tweaked or refactored.
                  >
                  > I wonder if there is a difference between the
                  clarity/comprehensibility of a
                  > design versus of its description/explanation?
                  >
                  > --
                  > Brad Appleton <brad AT bradapp.net>
                  > Agile CM Environments (http://blog.bradapp.net/)
                  > & Software CM Patterns (http://www.scmpatterns.com/)
                  > "And miles to go before I sleep." -- Robert Frost
                  >
                  >

                  --
                • Giovanni Asproni
                  Hi Brad, I fully agree with what you wrote. In April this year, I presented a session at the ACCU conference in UK (www.accu.org/conference) about simplicity
                  Message 8 of 15 , Jun 1, 2006
                  • 0 Attachment
                    Hi Brad,

                    I fully agree with what you wrote.

                    In April this year, I presented a session at the ACCU conference in UK
                    (www.accu.org/conference) about simplicity with the title "Simple,
                    Simplest or Simplistic?"

                    One of the main points of the presentation (it was aimed at programmers)
                    was that, very often, programmers confuse simple with the quickest hack
                    they can think of without fully appreciating the problem they are trying
                    to solve. This leads to *simplistic* solutions that, in the end, are
                    going to increase (unnecessarily) the complexity of the final product.

                    I've seen this problem both in agile and non-agile teams, especially
                    during times of high pressure--approaching deadline, overcommitment, etc.

                    Something that some people have difficulty in understanding is also that
                    simplicity depends on context, e.g., the problem being solved (the
                    simplicity of the on-board software for a jetliner cannot be judged with
                    the same parameters we would use for an inventory application for a
                    small shop), the technologies used, etc.

                    However, I'm not sure yet if the skills of the developers should be part
                    of the context or not: a solution that is simple for an expert may not
                    be simple for a beginner--after all, this is the whole point of becoming
                    an expert. I guess this fits in your 'Simple is not the same thing as
                    "easy to do/understand"' category.

                    Giovanni

                    Brad Appleton wrote:

                    >I just blogged at length on this subject at http://blog.bradapp.net/
                    >(as well as providing a list of web resources & famous quotations on the
                    >subject) and would be interested in people's impressions and commentary
                    >on what I jotted down in my blog-entry.
                    >
                    >Some relevant excerpts ...
                    >==========================
                    >- "Simple is not the same thing as "easy to do/understand."
                    >- "Simple design" is not the same thing as "simple to develop/deploy."
                    >- "Simple" is not the same thing as "good enough!"
                    >- "Simple" is not the same thing as "simplistic!"
                    >- What is "simple" for one request may not be "simple" for the whole!
                    >
                    >... The Agile Manifesto defines simplicity as "maximizing the amount of
                    >work not done." But I think that's a more accurate characterization of
                    >Lean than of simplicity.
                    >
                    >... Simplicity involves being able to see the whole from a system's
                    >thinking perspective while at the same time being able to focus in on
                    >what is relevant and essential and how it impacts the rest of the
                    >system. Sustainable simplicity often has to evolve or emerge on it's own
                    >from a set of simple guiding rules.
                    >
                    >The opposite of simplicity is complexity (as opposed to "hard" or
                    >"difficult" or "time-consuming" or "labor-intensive") ... Hiding
                    >complexity isn't the same as removing complexity.
                    >
                    >I think that true simplicity is about minimizing and managing overall
                    >complexity. For any non-trivial system, simplicity often has less to do
                    >with the number and kind of different things involved and more to do
                    >with the number and kind of interdependencies between them. Simplicity
                    >is less about managing "points" and "things" and more about managing
                    >rules and relationships.
                    >
                    >When dealing with large or complex systems (like most software, and
                    >software processes) the number of things (scale) and different types of
                    >things (diversity) that need to be managed is overwhelming. If we can
                    >come up with a modicum of modest, simple rules & principles to govern
                    >our design decisions in ways that helps us minimize and manage
                    >interdependencies, eliminate constraints, and remove waste, then we are
                    >on the path to solving the real problem and meeting stakeholder needs in
                    >a way that is both simple and sustainable.
                    >
                    >
                    >

                    --
                    Giovanni Asproni Email: gasproni@...
                    Director, Asprotunity Limited Mobile: +44 (0)791 746 0453
                    http://www.asprotunity.com Phone: +44 (0)207 788 7649
                    http://www.giovanniasproni.com Fax: +44 (0)870 762 3212
                  • Brad Appleton
                    ... I guess here I m thinking about the underlying problem to be solved. The problem to be solved may likely be quite complex (not-simple). And I m going to
                    Message 9 of 15 , Jun 6, 2006
                    • 0 Attachment
                      Ron Jeffries wrote:
                      > On Wednesday, May 31, 2006, at 3:10:27 PM, Brad Appleton wrote:
                      > I'd think that comprehensibility is likely a good indicator of
                      > simplicity. You suggest that something can be easy to understand yet
                      > still have undesirable interdependencies. I'd want to understand
                      > that notion better than I do now ...

                      I guess here I'm thinking about the underlying problem to be solved. The
                      problem to be solved may likely be quite complex (not-simple). And I'm
                      going to assert that a great deal of the complexity inherent in the
                      underlying problem has a high likelihood of being present in the
                      solution too.

                      The design might still be simple, but it nonetheless requires
                      understanding the problem (which may not be simple - and which may
                      contain some elements/dependencies we wish we didnt have to deal with :)
                      --
                      Brad Appleton <brad {AT} bradapp.net>
                      Agile CM Environments (http://blog.bradapp.net/)
                      & Software CM Patterns (www.scmpatterns.com)
                      "And miles to go before I sleep" -- Robert Frost
                    • Brad Appleton
                      ... Would not the problem its trying to solve also have to be understood? I think the ability to quickly complete a task with minimal knowledge can sometimes
                      Message 10 of 15 , Jun 6, 2006
                      • 0 Attachment
                        scrum@... wrote:
                        > Yes I would say that it primarily revolves around clarity /
                        > comprehensibility but also the ability to quickly complete a given task
                        > with minimal knowledge. For an object (design, diagram, document, code,
                        > anything really) to be deemed simple it has to first be understood.

                        Would not the problem its trying to solve also have to be understood?
                        I think the ability to quickly complete a task with minimal knowledge
                        can sometimes be more related to the comprehensibility of the underlying
                        problem than to the simplicity of the designed solution.


                        > I also think that simple may relate to something singluar. I believe
                        > anything with interdependencies where a change to one affects the other
                        > cannot be deemed simple, and if a change to one did not cause a change
                        > to the other then it cannot be an interdependency it is simply a loose
                        > link.

                        Sounds like the "Principle of Parsimony" or "Occams Razor"
                        see http://philosophy.wisc.edu/simplicity/



                        --
                        Brad Appleton <brad {AT} bradapp.net>
                        Agile CM Environments (http://blog.bradapp.net/)
                        & Software CM Patterns (www.scmpatterns.com)
                        "And miles to go before I sleep" -- Robert Frost
                      • Giovanni Asproni
                        ... I think the complexity of a problem is defined by the complexity of the simplest (for some definition of simplest) solution to it. I can t think of a
                        Message 11 of 15 , Jun 7, 2006
                        • 0 Attachment
                          Brad Appleton wrote:

                          >Ron Jeffries wrote:
                          >
                          >
                          >>On Wednesday, May 31, 2006, at 3:10:27 PM, Brad Appleton wrote:
                          >>I'd think that comprehensibility is likely a good indicator of
                          >>simplicity. You suggest that something can be easy to understand yet
                          >>still have undesirable interdependencies. I'd want to understand
                          >>that notion better than I do now ...
                          >>
                          >>
                          >
                          >I guess here I'm thinking about the underlying problem to be solved. The
                          >problem to be solved may likely be quite complex (not-simple). And I'm
                          >going to assert that a great deal of the complexity inherent in the
                          >underlying problem has a high likelihood of being present in the
                          >solution too.
                          >
                          >
                          I think the complexity of a problem is defined by the complexity of the
                          "simplest" (for some definition of simplest) solution to it. I can't
                          think of a problem with an inherent complexity higher than the
                          complexity of its solution (even if I see examples of the opposite
                          almost every day).

                          >The design might still be simple, but it nonetheless requires
                          >understanding the problem (which may not be simple - and which may
                          >contain some elements/dependencies we wish we didnt have to deal with :)
                          >
                          >
                          Have you got an example to show?

                          Giovanni

                          --
                          Giovanni Asproni Email: gasproni@...
                          Director, Asprotunity Limited Mobile: +44 (0)791 746 0453
                          http://www.asprotunity.com Phone: +44 (0)207 788 7649
                          http://www.giovanniasproni.com Fax: +44 (0)870 762 3212
                        • Brad Appleton
                          ... So if you dont have a solution yet, and just a problem statement - then the complexity of the problem is undefined/unknown? Im inclined to think that
                          Message 12 of 15 , Jun 8, 2006
                          • 0 Attachment
                            Giovanni Asproni wrote:
                            > I think the complexity of a problem is defined by the complexity of the
                            > "simplest" (for some definition of simplest) solution to it.

                            So if you dont have a solution yet, and just a problem statement - then
                            the complexity of the problem is undefined/unknown?

                            Im inclined to think that before there is even a solution, the problem
                            still has some number+variety of entities and their relationships. And
                            as those increase, so does the complexity of the problem (regardless of
                            whether I have a solution proposed yet)

                            > >The design might still be simple, but it nonetheless requires
                            > >understanding the problem (which may not be simple - and which may
                            > >contain some elements/dependencies we wish we didnt have to deal with :)
                            > >
                            > Have you got an example to show?

                            I think a number of "think outside the box" scenarios would fit here.
                            There's a common "puzzle" that involves four marbles in a small, fully
                            encased/enclosed plastic box that fits in your hand.

                            Each marble has its own "lane" from the center of the box to the corner
                            of the box, that is on a slight incline from the corner down to the
                            center. The normal starting point is all marbles are resting in their
                            little "crater" near the center of the small box. The objective is to
                            get all four marbles resting in the little "crater" of its corner of the
                            box, with each marble having to travel up its incline in order to get
                            there. If you title the box one way to get one marble in its corner, the
                            marble in the opposite corner slides out of its crater and goes back to
                            its center position.

                            If you are really good/delicate/careful at tilting just so and at
                            various angles, then after much time and diligence, you can get all the
                            marbles in the corners,

                            Or if it occurs to you to think of trying to do all the marbles at once,
                            instead of 1-2 at a time, then it might also occur to you to just "spin"
                            the box on its center and let physics and centrifugal force do the work
                            for you. And you'll be done in about 2-3 seconds. Plus the solution
                            still works in the same amount even if the container has more than 4
                            corners+marbles.

                            Another example related to software ... suppose you are tasked with the
                            job of implementing some kind of formal-inspection workflow+tracking
                            system (assume your customers hadnt heard of pair-programming, and when
                            told about it, they werent willing to adopt it just yet :-).

                            A formal inspection tends to have a set number and type of inspection
                            roles, a defined workflow, a specified set of data to track and
                            associated metrics/reports/triggers. Inspecting a particular change
                            might require one inspection-meeting or several inspection-meetings
                            (depending in part of the amount of materials to inspect and the amount
                            of time for each meeting).

                            One thing that can be tricky is figuring out which portions of the
                            "workflow" are practical to attempt to "strictly enforce" or not. It can
                            depend on levels of skill/discipline/trust/org-culture etc. The full
                            workflow is part of the problem statement, and does need to be
                            understood, but it may not all be needed in the solution design.
                            Similarly, whether or not the solution needs to know/care about multiple
                            inspections or inspection-meetings for a change is another way the
                            design can be made simpler or more complex, even though knowing about
                            that part of the problem and the issues involved with inspection times
                            and preparation times would still be necessary to understand and solve
                            the problem.

                            So I would say there are often times where it is necessary to grok
                            something of substantial complexity before understanding that the
                            solution may require very little (or even nothing) to achieve.
                            --
                            Brad Appleton <brad {AT} bradapp.net>
                            Agile CM Environments (http://blog.bradapp.net/)
                            & Software CM Patterns (www.scmpatterns.com)
                            "And miles to go before I sleep" -- Robert Frost
                          • Justin T. Sampson
                            ... Neat! I ve never seen that. ... I wonder, is this an example of something that is easy but not simple? That is, we ve already established that simple is
                            Message 13 of 15 , Jun 8, 2006
                            • 0 Attachment
                              On 6/8/06, Brad Appleton <Brad.Appleton@...> wrote:

                              > > > The design might still be simple, but it nonetheless
                              > > > requires understanding the problem (which may not be simple
                              > > > - and which may contain some elements/dependencies we wish
                              > > > we didnt have to deal with :)
                              > >
                              > > Have you got an example to show?
                              >
                              > I think a number of "think outside the box" scenarios would fit
                              > here. There's a common "puzzle" that involves four marbles in a
                              > small, fully encased/enclosed plastic box that fits in your
                              > hand.
                              >
                              > Each marble has its own "lane" from the center of the box to the
                              > corner of the box, that is on a slight incline from the corner
                              > down to the center. The normal starting point is all marbles are
                              > resting in their little "crater" near the center of the small
                              > box. The objective is to get all four marbles resting in the
                              > little "crater" of its corner of the box, with each marble
                              > having to travel up its incline in order to get there. If you
                              > title the box one way to get one marble in its corner, the
                              > marble in the opposite corner slides out of its crater and goes
                              > back to its center position.

                              Neat! I've never seen that.

                              > If you are really good/delicate/careful at tilting just so and
                              > at various angles, then after much time and diligence, you can
                              > get all the marbles in the corners,
                              >
                              > Or if it occurs to you to think of trying to do all the marbles
                              > at once, instead of 1-2 at a time, then it might also occur to
                              > you to just "spin" the box on its center and let physics and
                              > centrifugal force do the work for you. And you'll be done in
                              > about 2-3 seconds. Plus the solution still works in the same
                              > amount even if the container has more than 4 corners+marbles.
                              >
                              > [...]
                              >
                              > So I would say there are often times where it is necessary to
                              > grok something of substantial complexity before understanding
                              > that the solution may require very little (or even nothing) to
                              > achieve.

                              I wonder, is this an example of something that is easy but not
                              simple? That is, we've already established that simple is not
                              always easy, and maybe this is an example of the reverse. Spinning
                              the box is an *easy* solution for us to perform, but it takes
                              advantage of complex physical relationships between the balls and
                              the box.

                              Cheers,
                              Justin
                            • Giovanni Asproni
                              ... In general I d answer yes. However something very important, in my opinion, is the context in which the problem is stated, this includes the skills, and
                              Message 14 of 15 , Jun 10, 2006
                              • 0 Attachment
                                Brad Appleton wrote:

                                >Giovanni Asproni wrote:
                                >
                                >
                                >>I think the complexity of a problem is defined by the complexity of the
                                >>"simplest" (for some definition of simplest) solution to it.
                                >>
                                >>
                                >
                                >So if you dont have a solution yet, and just a problem statement - then
                                >the complexity of the problem is undefined/unknown?
                                >
                                >
                                In general I'd answer yes. However something very important, in my
                                opinion, is the context in which the problem is stated, this includes
                                the skills, and knowledge of the domain of the problem solver: for me
                                designing a small plane is problem of unknown complexity (I can only say
                                it would be very high), but it may be a no brainer for an airplane
                                engineer that designs jetliners for a living.

                                >Im inclined to think that before there is even a solution, the problem
                                >still has some number+variety of entities and their relationships. And
                                >as those increase, so does the complexity of the problem (regardless of
                                >whether I have a solution proposed yet)
                                >
                                >
                                Sometimes, apparently simple problems can have horrendously complicated
                                solutions.
                                Think of the proof of Fermat's last theorem. The problem statement is
                                very simple: the equation x^n + y ^n = z^n has no whole number solutions
                                for n > 2.
                                It required about 300 years to be proved, and the proof is so
                                complicated that only a few mathematicians can understand it. There are
                                mathematical theorems which look much more complicated, but actually
                                have far simpler proofs.
                                So, I think you're right, a problem has an inherent complexity
                                regardless of whether I have a solution to it, but how can I judge its
                                complexity if I don't have a solution?

                                >
                                >
                                >> >The design might still be simple, but it nonetheless requires
                                >> >understanding the problem (which may not be simple - and which may
                                >> >contain some elements/dependencies we wish we didnt have to deal with :)
                                >> >
                                >>Have you got an example to show?
                                >>
                                >>
                                >
                                >I think a number of "think outside the box" scenarios would fit here.
                                >There's a common "puzzle" that involves four marbles in a small, fully
                                >encased/enclosed plastic box that fits in your hand.
                                >
                                >Each marble has its own "lane" from the center of the box to the corner
                                >of the box, that is on a slight incline from the corner down to the
                                >center. The normal starting point is all marbles are resting in their
                                >little "crater" near the center of the small box. The objective is to
                                >get all four marbles resting in the little "crater" of its corner of the
                                >box, with each marble having to travel up its incline in order to get
                                >there. If you title the box one way to get one marble in its corner, the
                                >marble in the opposite corner slides out of its crater and goes back to
                                >its center position.
                                >
                                >If you are really good/delicate/careful at tilting just so and at
                                >various angles, then after much time and diligence, you can get all the
                                >marbles in the corners,
                                >
                                >Or if it occurs to you to think of trying to do all the marbles at once,
                                >instead of 1-2 at a time, then it might also occur to you to just "spin"
                                >the box on its center and let physics and centrifugal force do the work
                                >for you. And you'll be done in about 2-3 seconds. Plus the solution
                                >still works in the same amount even if the container has more than 4
                                >corners+marbles.
                                >
                                >
                                I think the context is very important here: someone with good knowledge
                                of classical physics would judge this problem as a simple one, since he
                                would know about centrifugal force; however, for someone with no clue of
                                physical laws it would be a very difficult one to solve.

                                >So I would say there are often times where it is necessary to grok
                                >something of substantial complexity before understanding that the
                                >solution may require very little (or even nothing) to achieve.
                                >
                                >
                                I agree with the above statement. I think we have more than a problem
                                and a solution here, but also a process to find a solution which can be
                                complex or simple depending on the context. My understanding--please
                                correct me if I'm wrong--is that you are relating the complexity of a
                                problem to the complexity of the process to find a solution, while I
                                tend to associate the complexity of a problem to the complexity of its
                                solution only--I think every problem is more complex to solve the first
                                time we do it, once we know the solution it becomes simpler (i.e., its
                                complexity depends on the complexity of implementing a solution, not
                                finding one).

                                Giovanni

                                --
                                Giovanni Asproni Email: gasproni@...
                                Director, Asprotunity Limited Mobile: +44 (0)791 746 0453
                                http://www.asprotunity.com Phone: +44 (0)207 788 7649
                                http://www.giovanniasproni.com Fax: +44 (0)870 762 3212
                              • David A Barrett
                                ... On the other hand, the easiest way for you to solve this problem would be to go hire an airplane engineer. This leads to something I believe to be a
                                Message 15 of 15 , Jun 12, 2006
                                • 0 Attachment
                                  >>So if you dont have a solution yet, and just a problem statement - then
                                  >>the complexity of the problem is undefined/unknown?
                                  >>
                                  >>
                                  >In general I'd answer yes. However something very important, in my
                                  >opinion, is the context in which the problem is stated, this includes
                                  >the skills, and knowledge of the domain of the problem solver: for me
                                  >designing a small plane is problem of unknown complexity (I can only say
                                  >it would be very high), but it may be a no brainer for an airplane
                                  >engineer that designs jetliners for a living.

                                  On the other hand, the easiest way for you to solve this problem would be
                                  to go hire an airplane engineer.

                                  This leads to something I believe to be a universal truth: Any problem
                                  that can be solved by simply throwing money at it ceases to be a problem,
                                  and becomes instead a management choice.


                                  Dave Barrett,
                                  Lawyers' Professional Indemnity Company
                                Your message has been successfully submitted and would be delivered to recipients shortly.