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

[extremeprogramming] Re: All the extras (I don't know about: Elves in the Night)

Expand Messages
  • Robert C. Martin
    ... In a large system, trace logs become invaluable when problems occurr. In small systems, or systems that are not particularly prone to error, they are not
    Message 1 of 38 , Jan 4, 2000
      > -----Original Message-----
      > From: Dave Thomas [mailto:Dave@...]

      > Sometimes, though, tracing is what you do to find out _why_ a unit
      > test failed. Adding tracing retroactively when a particular
      > test fails
      > way down the development pike may be far more expensive that asking
      > for it as you go along.

      In a large system, trace logs become invaluable when problems occurr. In
      small systems, or systems that are not particularly prone to error, they
      are not particularly useful. In the past, I have grown the system
      without trace logs until I felt they were necessary; and then I went
      back and added them to the modules that were the least stable. In a few
      instances, I added them throughout the system.

      Adding trace statements later is not much more expensive than adding
      them at first. Adding them selectively saves both time and effort.
      Adding them after the fact allows me to be selective.

      BTW, I presume that the extensive unit testing of XP (which has to be
      seen to be believed) will push back the threshold on the need for
      tracing quite a ways.

      Finally, trace statements make life easier for engineers. Given certain
      failure modes, the engineers can use the trace logs to determine what
      went wrong. But does this add value to the customer? In certain
      circumstances it certainly does. In others, it's not so clear. Does
      MS-Word create a trace log for example? Do the zillions of consumers
      ever send that trace log into Microsoft when MS-Word fails?

      Thus, I would suggest that even the creation of a trace log is something
      that the customer should agree to. Engineers may propose it as a story:
      "increase speed and accuracy of problem diagnosis". But if the
      customers don't view this as an important problem to solve, they have a
      right to prevent you from expending their money on it.

      Robert C. Martin | OO Mentoring | Training Courses:
      Object Mentor Inc. | rmartin@... | OOD, Patterns, C++,
      PO Box 85 | Tel: (800) 338-6716 | Extreme Programming.
      Grayslake IL 60030 | Fax: (847) 548-6853 |

      "One of the great commandments of science is:
      'Mistrust arguments from authority.'" -- Carl Sagan
    • Robert C. Martin
      Tom Kreitzberg wrote in message news:387364E4.C0A3E6CC@jhuapl.edu... ... There is no fundamental difference between pre XP Object
      Message 38 of 38 , Jan 5, 2000
        Tom Kreitzberg <Tom.Kreitzberg@...> wrote in message

        > But I think "flexibility" means different things to XP and,
        > shall we say, pre-XP OMA. In XP, doesn't it primarily mean
        > once and only once? In pre-XP OMA, doesn't it primarily mean
        > OCP and low coupling? When I wrote that XP "is structured so
        > that inflexible designs are cheap to change," I meant inflexible
        > in this second sense.

        There is no fundamental difference between pre XP Object Mentor, and
        post XP
        Object Mentor except that we have identified XP as the process we like
        use. Even this is not a big shift for us, since XP is very similar in
        spirit and practice to the unnamed process we have used for years.
        are differences, certainly -- specifically in the areas of pair
        and test first programming; but these are differences in intensity, not
        philosophy. As for the rules governing simplity, the planning game,
        iterations, etc, we were very closely aligned.

        Flexibility means the same to me now as it did five years ago. The
        to add or change significant amounts of functionality while changing a
        minimum of exsiting code -- i.e. the OCP. OnceAndOnlyOnce leads to this
        goal just as the OO design principles do. It is my goal over the next
        several months to integrate the principles and XP.
      Your message has been successfully submitted and would be delivered to recipients shortly.