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
    ... And (at the risk of causing global offense) we re back to the old Nuremberg defense - the customer told me to do it (or the anti-defense - the customer
    Message 1 of 38 , Jan 4, 2000
    • 0 Attachment
      "Robert C. Martin" <rmartin@...> writes:

      > 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.

      And (at the risk of causing global offense) we're back to the old
      Nuremberg defense - the customer told me to do it (or the anti-defense
      - the customer never told me to do it). Somehow, I don't find that a
      professional attitude. The customer is paying me to do the work
      because I have particular skills and experience they don't have--they
      are accountants, or bookmakers, or marketing folks, and I'm
      JustAProgrammer. They don't want to know, nor do they have time to
      find out, every single arcane detail of the work I do. I'm paid,
      sometimes well ;-), to take that load from them.

      The alternative, which you seem to advocating, is that I can't take
      any technical decision which impacts timescale without getting the
      customer to agree to it. But _every_ technical decision affects
      timescales, even if only minutely.

      I can't see any team stopping work to drag the customer over:

      "Look at that. We just failed a unit test. Now this is what we need
      to do. Dave over there is about to <hushed awe> enter the
      debugger. Once there, we propose we type some commands to try to
      determine how this particular variable got set to 42.

      Do you, Mr Customer, agree to him entering the debugger.

      OK, thank you. <over shoulder: "Permission to enter debugger">

      Now, can he type the command 'bt'?

      etc...

      But finding that same bug by inserting tracing statements is an
      equivalent technical action. Isn't it equally silly to drag the
      customer into the decision to add tracing?

      I'm beginning to wonder if the reason that XP is less risky is that it
      simply pushes that risk off on the customer ;-)

      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.