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

Re: [XP] Signing Your Work vs Code Ownership

Expand Messages
  • Ron Jeffries
    ... Here we get to the root of my question so long ago. If you re doing XP, you should already /know/ who has done most of the work. After all, you were in the
    Message 1 of 78 , Feb 1, 2002
      Around Thursday, January 31, 2002, 11:43:22 PM, alex@... wrote:

      > My gut tells me, sign your code. If someone else needs to modify it
      > later and can't grok it after staring at it for a few minutes, or if
      > he wants to know why you refactored things one way rather than
      > another, then he can walk across the room and ask you. Maybe you'll
      > say "I don't know what I was thinking" or maybe you'll say "Oh, there
      > was a very good reason for that that's not obvious from the code" or
      > maybe you'll say "I signed it a year ago, and it's been refactored 8
      > times, go talk to Bill" -- any scenario, there's no harm done from
      > signing.

      Here we get to the root of my question so long ago. If you're doing
      XP, you should already /know/ who has done most of the work. After
      all, you were in the room when they signed up for it last Monday ,
      they reported on it at yesterday's stand-up meeting, you paired with
      them this morning, and you can always just raise your voice a bit and
      ask "who knows about the WangDangDoodle class".

      So if our reason for wanting code signing is that we want to know who
      did things, it's a "process smell". It doesn't matter /why/ you want
      to know.

      If you want to know so you can blame them ...
      If you want to know so you can hug them ...
      If you want to know so you can pair with them ...
      If you want to know so someone will be more careful ...

      If you need a signature to find out what someone in the room is
      doing, it's a process smell.

      If you want to sign your work because you're proud of it, go for it.

      If you think you /need/ signatures, there's some other problem.
      Fix that.

      Ron Jeffries
      www.XProgramming.com
      It is not because things are difficult that we do not dare,
      it is because we do not dare that they are difficult. --Seneca
    • 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.