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

Re: [XP] Signing Your Work vs Code Ownership

Expand Messages
  • Gauti Þór Reynisson
    From: Pete McBreen, McBreen.Consulting ... Speaking for myself, then I can t see how you enforce a signing policy in a collective
    Message 1 of 78 , Feb 1 2:20 AM
    • 0 Attachment
      From: "Pete McBreen, McBreen.Consulting" <mcbreenp@...>
      > As another person who advocates signing our work I have to say that I do
      > not see the polarity implied in the title of this thread "Signing Your
      > Work vs Code Ownership". Signing your work is one aspect of software
      > development, code ownership is a different aspect.


      Speaking for myself, then I can't see how you enforce a "signing" policy in
      a collective code ownership environment. Any name you put on a file is
      meaningless because at least 80% of the team has edited the code. When I
      open up a file and see a name at the top, what does that tell me? The name
      of the person who created the file? What do I gain from that piece of
      information?

      And then again, what do I loose... nothing I guess, but it would indicate to
      me that there is not true collective code ownership, as I understand the
      term... a process smell as Ron indicated.

      cheers,

      Gauti
    • 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 6:32 PM
      • 0 Attachment
        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.