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
  • Dave Thomas
    ... 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
    Message 1 of 38 , Jan 3, 2000
    • 0 Attachment
      Patrick Logan <patrickdlogan@...> writes:

      > Dave Thomas writes:
      > >
      > > Same with something like logging or tracing. Often, this is a
      > > facility that's useful to the development team, not the business
      > > users. So I'd normally add it without consultation.
      >
      > Tracing is something I do to solve complex, primarily hundreds++
      > multi-user, problems. Maybe it could be said that if I wrote unit
      > tests well enough, then I would not need to trace complex multi-user
      > scenarios. I hope some day that is true! I can tell you though I am
      > (1) either not smart enough to hold so many ideas in my head; or (2)
      > not diligent enough to find out that I am smart enough; or (3) too
      > embarrassed to ask my friends to help me find out.
      >
      > So I would expect to add tracing to a system as soon as one of these
      > kinds of problems reared its ugly head.

      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.

      Of course, the ideal solution here is AOP, or features such as those
      in Ruby that let you add tracing orthogonally to the source.

      Regards

      Dave


      --
      Thomas Consulting.
      Innovative and successful developments with Unix, Java, C, and C++.

      Now in bookstores:
      The Pragmatic Programmer. www.pragmaticprogrammer.com/ppbook/
    • 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
      • 0 Attachment
        Tom Kreitzberg <Tom.Kreitzberg@...> wrote in message
        news:387364E4.C0A3E6CC@......

        > 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
        to
        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.
        There
        are differences, certainly -- specifically in the areas of pair
        programming
        and test first programming; but these are differences in intensity, not
        in
        philosophy. As for the rules governing simplity, the planning game,
        quick
        iterations, etc, we were very closely aligned.

        Flexibility means the same to me now as it did five years ago. The
        ability
        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.