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

Re: [XP] Why NOT XP?

Expand Messages
  • Dakshinamurthy Karra
    ... For every example we give, we can find a counter example. One of the best run projects of mine is developing a TCP/IP stack and command tools for DOS. The
    Message 1 of 102 , Oct 29, 2004
    • 0 Attachment
      On Fri, 29 Oct 2004 21:18:22 -0700, Kent Beck <kentb@...> wrote:
      >
      > I worked on a debugger for a Fortran 90 compiler for three years. A
      > programming language is the ultimate in fixed specification. It turns
      > out that there are many priority issues involved: which optimizations to
      > implement, whether to make those optimizations debuggable, how much to
      > optimize the compiler itself. There were valid technical and business
      > reasons to sequence these features. If we had been in better touch with
      > our customers, we would have produced a more valuable product.
      >
      For every example we give, we can find a counter example. One of the
      best run projects of mine is developing a TCP/IP stack and command
      tools for DOS. The whole thing is accomplished using commands on unix
      (ftp, telnet, rsh etc.) and by the developers verifying the
      functionalities by comparing them. The product is quite successful in
      intended markets.

      > The team needs to experience collective accomplishment. If I was
      > implementing a protocol stack, I would work hard to have one teensy-tiny
      > feature working end-to-end in the first week. The next week I'd add
      > another feature. The features are also a concrete measure of progress
      > useful to the rest of the organization for planning and coordination.
      >
      I agree with this sentiment. Even when we are developing the
      applications, we used go bit-by-bit and had bi-weekly demo sessions
      where we used to *show-off* to the marketing/sales teams. This is
      almost 10 years back.

      > A fixed specification is not a reason not to practice XP.
      >
      Not really. But I can't see the intended value of having an on-site
      customer in this case and questioning the value of only this practice.

      KD
      --
      Dakshinamurthy Karra
      CTO, Subex Systems Ltd.(http://www.subexsystems.com)
    • Erik Meade
      Hey Kent, long time no see ;) ... I find that if it isn t a teachable moment, it would be easier to do it myself. I usually still tell them anyway, and often
      Message 102 of 102 , Dec 27, 2004
      • 0 Attachment
        Hey Kent, long time no see ;)

        > It *is* easier to tell someone else what to do than to do it yourself.
        > However, doing the behavior myself it is a more effective way to influence
        > others. Part of modeling is practicing the behavior yourself. Part of it is
        > waiting for the teachable moment, where someone else is ready to learn
        > something.

        I find that if it isn't a teachable moment, it would be easier to do it
        myself. I usually still tell them anyway, and often I try to remove a
        barrier or two, but when you have too much to do, something has to give.
        At least if you are pair programming you can show them.

        Erik Meade
      Your message has been successfully submitted and would be delivered to recipients shortly.