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

Re: [XP] Re: Agile Developers and Jehovah Witnesses - separated at birth?

Expand Messages
  • Brad Appleton
    ... Well - as I mentioned this was numerous projects and teams between 1985-1995 (and we paired less than 20%). Pairing (or not) didnt really effect TCO for us
    Message 1 of 15 , Nov 27, 2005
      Ron Jeffries wrote:
      >>So I would say my experience has been that pairing doesnt have too much
      >>impact on the effectiveness of TCO. I think its possible that more
      >>pairing might mean less updates after-the-fact to correct things like
      >>coding-standards violations or other fixes, etc., but it didnt really
      >>change our feelings about the relative goodness or effectiveness of TCO.
      >
      > How is it that one data point, "we paired about 20% and everything
      > went fine", tell us much at all about the effect of more, or less,
      > pairing?

      Well - as I mentioned this was numerous projects and teams between
      1985-1995 (and we paired less than 20%).

      Pairing (or not) didnt really effect TCO for us as far as I can tell. We
      still did code-reviews either way. Pairing for us would typically catch
      things before the code-review. If something made it past code reviews
      and (possibly additionally) pairing, that was not caught by testing, it
      was usually either an issue of coding standards, or of design or
      requirements.

      What I call a "collective ownership update" is when someone makes a
      change to code that wasnt written by them in order to correct a problem
      (e.g., coding standard violation) or to improve (simplify) the design.

      Im assuming that more pairing would have perhaps caught more of these
      things and that the effect on collective ownership would have been that
      fewer "collective ownership" updates would have been needed. So it would
      have conceivably decreased some parallel development of certain files.

      * Some folks would consider that as hampering the effectiveness of TCO,
      but we would more likely have felt just the opposite

      Where it made the biggest difference IMHO is was if the collective
      ownership update was made its own separate change (and committed right
      aferward) or if it was done as part of another task someone was working
      on, and wasnt "committed" until they finished the rest of the task.

      What I saw was that if the "collective ownership" change was simply
      fixing adherence to coding standards, it didnt seem to make too much
      difference if it was committed "by itself" or as part of a larger task.

      However, if it was fixing a behavioral problem or fixing/improving a
      structural issue in the code, then fixing it as part of a larger task
      was perhaps easier for the developer, but not as useful to the rest of
      the team. If was better for the team to be able to see (and
      build/integrate) with that behavioral or structural change sooner rather
      than later (no big surprise here).

      --
      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep" --Robert Frost
    Your message has been successfully submitted and would be delivered to recipients shortly.