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

Re: [scrumdevelopment] Simple ain't Easy: Myths and Misunderstandings about Simplicity

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.