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

Oversolving Poor Design

Expand Messages
  • Chris Morris
    http://clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/AgileDevelopment/OversolvingPoorDesign [I ll admit, it feels a little like I m taking some
    Message 1 of 7 , Sep 1, 2004
      http://clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/AgileDevelopment/OversolvingPoorDesign

      [I'll admit, it feels a little like I'm taking some liberties in the
      following text, but there's something to it that's resonating with me
      that I wanted to try to capture.]

      Working with code always requires a design decision of some sort. What
      code will I add/change/delete, and where will I do it? Typically,
      inexperienced teams make these design decisions on the fly, when they're
      needed, but they make poor choices and the codebase becomes buggy.

      What's interesting to me at this point, is that instead of reacting to
      "we don't design well on the fly" with "let's figure out how to design
      well on the fly", they react with "let's design well ahead of time so we
      won't have to know how to design well on the fly."

      Then they create a design process that is heavy enough to be time
      consuming enough to be too expensive to actually implement on the fly,
      when design decisions are needed, so all they are left with is their
      informal design abilities, which haven't been improved, and the codebase
      suffers.

      What's even more interesting now, is the tendancy to not dump the formal
      design process as a failed attempt, but to blame themselves for not
      being disciplined enough in using this process, even though it seems to
      have shown it's the wrong tool for the job. Formal design gets a revamp,
      and the undeveloped skill of making good design decisions on the fly
      remains undeveloped, and the codebase continues to suffer.

      Some teams will eventually start to improve their ability to make good
      design decisions on the fly without a formal process, but then still
      keep the formal process around and now start making some sort of
      arbitrary distinction between tasks that get designed by a formal
      process up front and those that are somehow different enough (but really
      aren't) to be okay for the informal design. Now we have process
      duplication, which may not be ineffective, but surely is wasteful risks
      the same sorts of problems that duplicate code does.

      --
      Chris
      http://clabs.org/blogki
    • Nick Robinson
      Chris, Do think that maybe part of the problem is that due to the old diagram showing: Analysis- Design- Implementation- Test- Release- Maintenance (or there
      Message 2 of 7 , Sep 2, 2004
        Chris,

        Do think that maybe part of the problem is that due to the old diagram showing:

        Analysis->Design->Implementation->Test->Release->Maintenance (or there abouts)

        design doesnt occur during implementation? Design occurs at the whiteboard, or in <insert modelling tool of choice here> and once you are done, you
        implement your design in code. Thats not true of course. As you say, each tempered code change is based in realtime on a design decision, effective
        or not. My impression and experience is that in a more formal process, moving code around seems less of a design process, and more of a final cutting
        the code step after all the hard work has been done. But formal process doesnt deal with the expertise required when making decisions about where to
        move or shape the code we work on. It is a skill in its own right, based on realtime design decisions, refactoring principles, common sense and
        experience. Designing on the whiteboard isnt the same as designing as you code, but nonetheless both have equal stature in terms of their importance.
        Each requires its own schedule in the personal development timetable of any professional wanting to improve their overall ability.

        "Cutting the code is the easy bit. Being able to design, and build models is the difficult part of software. Anyone can code."
        - Old boss of large company I worked at, almost verbatim.

        Nick.

        Chris Morris <chrismo@...> wrote:

        : http://clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/AgileDevelopment/OversolvingPoorDesign
        :
        : [I'll admit, it feels a little like I'm taking some liberties in the
        : following text, but there's something to it that's resonating with me
        : that I wanted to try to capture.]
        :
        : Working with code always requires a design decision of some sort. What
        : code will I add/change/delete, and where will I do it? Typically,
        : inexperienced teams make these design decisions on the fly, when they're
        : needed, but they make poor choices and the codebase becomes buggy.
        :
        : What's interesting to me at this point, is that instead of reacting to
        : "we don't design well on the fly" with "let's figure out how to design
        : well on the fly", they react with "let's design well ahead of time so we
        : won't have to know how to design well on the fly."
        :
        : Then they create a design process that is heavy enough to be time
        : consuming enough to be too expensive to actually implement on the fly,
        : when design decisions are needed, so all they are left with is their
        : informal design abilities, which haven't been improved, and the codebase
        : suffers.
        :
        : What's even more interesting now, is the tendancy to not dump the formal
        : design process as a failed attempt, but to blame themselves for not
        : being disciplined enough in using this process, even though it seems to
        : have shown it's the wrong tool for the job. Formal design gets a revamp,
        : and the undeveloped skill of making good design decisions on the fly
        : remains undeveloped, and the codebase continues to suffer.
        :
        : Some teams will eventually start to improve their ability to make good
        : design decisions on the fly without a formal process, but then still
        : keep the formal process around and now start making some sort of
        : arbitrary distinction between tasks that get designed by a formal
        : process up front and those that are somehow different enough (but really
        : aren't) to be okay for the informal design. Now we have process
        : duplication, which may not be ineffective, but surely is wasteful risks
        : the same sorts of problems that duplicate code does.
      • Michael Feathers
        ... Very true. Frankly, it is hard for many people to see what they do as design in the beginning. Often of the first steps is to get them out of the habit
        Message 3 of 7 , Sep 2, 2004
          Chris Morris wrote:

          >http://clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/AgileDevelopment/OversolvingPoorDesign
          >
          >[I'll admit, it feels a little like I'm taking some liberties in the
          >following text, but there's something to it that's resonating with me
          >that I wanted to try to capture.]
          >
          >Working with code always requires a design decision of some sort. What
          >code will I add/change/delete, and where will I do it? Typically,
          >inexperienced teams make these design decisions on the fly, when they're
          >needed, but they make poor choices and the codebase becomes buggy.
          >
          >What's interesting to me at this point, is that instead of reacting to
          >"we don't design well on the fly" with "let's figure out how to design
          >well on the fly", they react with "let's design well ahead of time so we
          >won't have to know how to design well on the fly."
          >
          >Then they create a design process that is heavy enough to be time
          >consuming enough to be too expensive to actually implement on the fly,
          >when design decisions are needed, so all they are left with is their
          >informal design abilities, which haven't been improved, and the codebase
          >suffers.
          >
          >
          >

          Very true. Frankly, it is hard for many people to see what they do as
          design in the beginning. Often of the first steps is to get them out of
          the habit of adding code to existing methods.


          Michael Feathers
          www.objectmentor.com
        • George Dinwiddie
          ... Very good! ... This, I think, is less universal than what went before. There are many ways that the design process runs into the weeds, here. The
          Message 4 of 7 , Sep 2, 2004
            On Wed, Sep 01, 2004 at 11:59:00PM -0500, Chris Morris wrote:
            > http://clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/AgileDevelopment/OversolvingPoorDesign
            >
            > [I'll admit, it feels a little like I'm taking some liberties in the
            > following text, but there's something to it that's resonating with me
            > that I wanted to try to capture.]
            >
            > Working with code always requires a design decision of some sort. What
            > code will I add/change/delete, and where will I do it? Typically,
            > inexperienced teams make these design decisions on the fly, when they're
            > needed, but they make poor choices and the codebase becomes buggy.
            >
            > What's interesting to me at this point, is that instead of reacting to
            > "we don't design well on the fly" with "let's figure out how to design
            > well on the fly", they react with "let's design well ahead of time so we
            > won't have to know how to design well on the fly."

            Very good!

            > Then they create a design process that is heavy enough to be time
            > consuming enough to be too expensive to actually implement on the fly,
            > when design decisions are needed, so all they are left with is their
            > informal design abilities, which haven't been improved, and the codebase
            > suffers.

            This, I think, is less universal than what went before. There are many
            ways that the "design process" runs into the weeds, here. The common
            element is that, not being good at designing in the small, the same
            people are not good at designing in the large.

            > What's even more interesting now, is the tendancy to not dump the formal
            > design process as a failed attempt, but to blame themselves for not
            > being disciplined enough in using this process, even though it seems to
            > have shown it's the wrong tool for the job. Formal design gets a revamp,
            > and the undeveloped skill of making good design decisions on the fly
            > remains undeveloped, and the codebase continues to suffer.
            >
            > Some teams will eventually start to improve their ability to make good
            > design decisions on the fly without a formal process, but then still
            > keep the formal process around and now start making some sort of
            > arbitrary distinction between tasks that get designed by a formal
            > process up front and those that are somehow different enough (but really
            > aren't) to be okay for the informal design. Now we have process
            > duplication, which may not be ineffective, but surely is wasteful risks
            > the same sorts of problems that duplicate code does.

            These paragraphs blur your point, for me.

            - George
          • jhrothjr
            ... page=/ComputersAndTechnology/AgileDevelopment/OversolvingPoorDesign ... the ... me ... What ... they re ... to ... design ... so we ... fly, ... their ...
            Message 5 of 7 , Sep 2, 2004
              --- In extremeprogramming@yahoogroups.com, Chris Morris
              <chrismo@c...> wrote:
              > http://clabs.org/blogki/blogki.cgi?
              page=/ComputersAndTechnology/AgileDevelopment/OversolvingPoorDesign
              >
              > [I'll admit, it feels a little like I'm taking some liberties in
              the
              > following text, but there's something to it that's resonating with
              me
              > that I wanted to try to capture.]
              >
              > Working with code always requires a design decision of some sort.
              What
              > code will I add/change/delete, and where will I do it? Typically,
              > inexperienced teams make these design decisions on the fly, when
              they're
              > needed, but they make poor choices and the codebase becomes buggy.
              >
              > What's interesting to me at this point, is that instead of reacting
              to
              > "we don't design well on the fly" with "let's figure out how to
              design
              > well on the fly", they react with "let's design well ahead of time
              so we
              > won't have to know how to design well on the fly."
              >
              > Then they create a design process that is heavy enough to be time
              > consuming enough to be too expensive to actually implement on the
              fly,
              > when design decisions are needed, so all they are left with is
              their
              > informal design abilities, which haven't been improved, and the
              codebase
              > suffers.
              >
              > What's even more interesting now, is the tendancy to not dump the
              formal
              > design process as a failed attempt, but to blame themselves for not
              > being disciplined enough in using this process, even though it
              seems to
              > have shown it's the wrong tool for the job. Formal design gets a
              revamp,
              > and the undeveloped skill of making good design decisions on the
              fly
              > remains undeveloped, and the codebase continues to suffer.
              >
              > Some teams will eventually start to improve their ability to make
              good
              > design decisions on the fly without a formal process, but then
              still
              > keep the formal process around and now start making some sort of
              > arbitrary distinction between tasks that get designed by a formal
              > process up front and those that are somehow different enough (but
              really
              > aren't) to be okay for the informal design. Now we have process
              > duplication, which may not be ineffective, but surely is wasteful
              risks
              > the same sorts of problems that duplicate code does.

              What puzzles me about this is that XP has the TDD process, which
              includes emergent design via refactoring to remove duplication. If
              you start doing this for real, I'd expect that you'd find a balance
              point between explicit design and emergent design that worked for
              you, and over time would move more toward emergent design.

              To add a side note, I'm making a distinction between "up front
              design" and "just in time" design here, and it's not the same as
              between explicit design and emergent design. Explicit design can
              be "just in time", and lots of up front designs benefit from a good
              dose of emergent design - those ideas didn't exist before you saw
              what showed up on the drawing board.

              John Roth
              (still working from a friend's system.)
              >
              > --
              > Chris
              > http://clabs.org/blogki
            • Chris Morris
              ... Ah, excellent point. ... I hear you -- thanks for the feedback :-) -- Chris http://clabs.org
              Message 6 of 7 , Sep 2, 2004
                George Dinwiddie wrote:

                >This, I think, is less universal than what went before. There are many
                >ways that the "design process" runs into the weeds, here. The common
                >element is that, not being good at designing in the small, the same
                >people are not good at designing in the large.
                >
                >
                Ah, excellent point.

                >>What's even more interesting now, is the tendancy to not dump the formal
                >>design process as a failed attempt, ...
                >>
                >>Some teams will eventually start to improve their ability to make good
                >>design decisions on the fly without a formal process, ...
                >>
                >>
                >
                >These paragraphs blur your point, for me.
                >
                >
                I hear you -- thanks for the feedback :-)

                --
                Chris
                http://clabs.org
              • Chris Morris
                ... I like the just in time phrase. I think something like it floatin through my noggin last night, but never solidified. If the steps for up front are
                Message 7 of 7 , Sep 2, 2004
                  jhrothjr wrote:

                  >To add a side note, I'm making a distinction between "up front
                  >design" and "just in time" design here, and it's not the same as
                  >between explicit design and emergent design. Explicit design can
                  >be "just in time", and lots of up front designs benefit from a good
                  >dose of emergent design - those ideas didn't exist before you saw
                  >what showed up on the drawing board.
                  >
                  >
                  I like the "just in time" phrase. I think something like it floatin'
                  through my noggin' last night, but never solidified. If the steps for
                  "up front" are too clunky, then the developers still need a way to
                  produce good code for the "just in time" instances.

                  --
                  Chris
                  http://clabs.org
                Your message has been successfully submitted and would be delivered to recipients shortly.