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

Signing Your Work vs Code Ownership

Expand Messages
  • gorowitch
    1. THE QUESTION Is signing your work acceptable in an XP environment ? 2. WHY IT IS. If ... Signing your work doesn t necessarily imply code ownership it is
    Message 1 of 78 , Jan 31, 2002
      1. THE QUESTION

      Is signing your work acceptable in an XP environment ?

      2. WHY IT IS.

      If ... Signing your work doesn't necessarily imply code ownership it
      is acceptable.

      Some advantages might be:
      -> It might reduce communication overhead ( you immediately know who
      to talk to ).

      -> It might indicate places where the knowledge isn't sufficienlty
      spread ( all by the same author/or pair of authors )

      3. WHY IT IS NOT.

      If might eventually lead to code ownership which is off course counter
      -XP.

      4. SOME ISSUES

      Ron Jeffries has already pointed out some issues, I've included these
      below.

      Around Wednesday, January 02, 2002, 3:39:59 AM, Sven Gorts wrote:

      > At the XP-site I read:

      > ... We do not practice code ownership. ...

      > And I really think that this is great advice. In practice, that is
      on
      > projects that don't use XP this well intended advice is often used
      as an
      > excuse to avoid signing the source code. This often results in
      sections of
      > really poor code that nobody has written. Some kind of a "quick and
      dirty
      > and then hide" attitude. I therefore propose that any
      programmer/pair of
      > programmers should always sign his/their code.

      Try it. See what happens. And tell the rest of us.

      Some issues and questions:

      If there is really poor code that no one has written, why has no one
      turned it into really good code? Does this suggest that the team
      doesn't feel team ownership?

      Will signed code help people know who to pair with when code needs
      changing ... or will it deter them from changing it because it
      "belongs" to someone else?

      Can you tell from the code management system who wrote the "really
      poor code"? Or do you in fact already know? Is it coming from
      everyone, from just a few, or from just one person? For which of
      these
      will signing make the code better?

      Has the team talked about "poor code"? Have they reached any
      agreement
      about it?

      The idea has the feeling of a neat little idea that could work. But
      neat little ideas can backfire. How could this one backfire?

      Anyway, if you try it, please let us know how it turns out. I'd watch
      for the effect on the feeling of ownership "territory".

      Ron Jeffries
      www.XProgramming.com
      You can observe a lot by watching. --Yogi Berra

      Kind Regards,
      Sven.
    • Jim Standley
      This has been a very long thread already, so I ll try to weigh in quickly with a few practices that have made us happy. When modifying code significantly add a
      Message 78 of 78 , Feb 4, 2002
        This has been a very long thread already, so I'll try to weigh in quickly
        with a few practices that have made us happy.

        When modifying code significantly add a comment. Always put it in the
        method header, sometimes duplicated in the code if it's a long method and
        it's not obvious what I did. Our standard format is:

        // mm/dd/yyyy My Name Did so and so.

        When appropriate include a defect report reference, or a story or use case.

        // mm/dd/yyyy CQ1234 My Name Did something else

        When checking in code, put a similar comment in the VC tool comments. On
        one project I made a browser for VC comments and ran it daily to see what
        had been going on in the code lately. It linked into the VC diff tool and a
        code browser to make monitoring progress easy.

        In Java we omit the @author tag. The author is of very little interest when
        reading API docs to see what something does. For new classes, we use the
        same comment format, but the "did what" just says "New".

        The main value of all this in the code is to help somebody who revisits code
        they haven't seen in a while and asks "What the heck happened while I wasn't
        looking!" A little explanation of the reason for a change goes a long way.
        If it doesn't go far enough, the author may still be around to ask. We've
        also found it useful when a user asks "How long has it been doing this?"
        whether it's a good thing or a bad thing that it's doing.

        I think these comments work regardless of your concepts of ownership and
        responsibility by group or individual. I try to always write things I'm
        happy to put my name on. If I'm not happy, it's a tip to rethink the code.
        Of course in the end I'm not above putting in comments like "This section
        compromises x to optimize y." or a favorite "I have no idea why this works
        but it avoids bug a in window z."
      Your message has been successfully submitted and would be delivered to recipients shortly.