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

How can refactoring and collective code ownership possibly go hand in hand?

Expand Messages
  • peter@vanrooijen.com
    If it is my duty to refactor at every opportunity I see to improve code, and I can change all the code, and my pair refactors a lot during the completion of a
    Message 1 of 8 , Mar 1, 2001
      If it is my duty to refactor at every opportunity I see to improve
      code, and I can change all the code, and my pair refactors a lot
      during the completion of a task, as do my fellow pairs:

      - isn't integration going to be extremely complicated? I mean, we
      worked adding to and refactoring a code base that has has been
      updated by an average of 2 other pairs (assume 5 pairs) before we get
      to integrate our new stuff.

      - what do we do about the tests that we changed, because others have
      changed tests as well. We can easily achieve 100% test success after
      integrating if we don't actually integrate, but throw away what the
      others have put in before us. How do we go about deciding which tests
      we need to have running at 100% after the integration?

      Oh, and hi, I already love this group. Been reading up on it in the
      archive, and I feel this is the place to ask the tough questions that
      have bugged me for a long time. Hope you don't mind, and have some
      insightful answers to share.

      Regards,

      Peter van Rooijen
    • azami@speakeasy.net
      ... get ... Only do refactorings that: a) make your task at hand easier to complete, or b) are changes to the code you are adding/changing anyway to complete
      Message 2 of 8 , Mar 1, 2001
        --- In extremeprogramming@y..., peter@v... wrote:
        > If it is my duty to refactor at every opportunity I see to improve
        > code, and I can change all the code, and my pair refactors a lot
        > during the completion of a task, as do my fellow pairs:
        >
        > - isn't integration going to be extremely complicated? I mean, we
        > worked adding to and refactoring a code base that has has been
        > updated by an average of 2 other pairs (assume 5 pairs) before we
        get
        > to integrate our new stuff.

        Only do refactorings that:
        a) make your task at hand easier to complete, or
        b) are changes to the code you are adding/changing anyway to complete
        your task (this covers the "the tests run, now let's make the code as
        nice as we can" refactoring time)

        > - what do we do about the tests that we changed, because others have
        > changed tests as well. We can easily achieve 100% test success after
        > integrating if we don't actually integrate, but throw away what the
        > others have put in before us. How do we go about deciding which
        tests
        > we need to have running at 100% after the integration?

        You can only remove a unit test if/when you remove the functionality
        it tests. Which you should do if and only if that code is not
        supporting any stories. "It made integration easier" is not an
        allowed excuse. If you accidentally do remove required functionality
        AND its unit tests, the acceptance tests will detect that
        such-and-such story no longer works and you'll have to fix it
        (possibly by recovering earlier versions from your repository and
        re-integrating).

        > Oh, and hi, I already love this group. Been reading up on it in the
        > archive, and I feel this is the place to ask the tough questions
        that
        > have bugged me for a long time. Hope you don't mind, and have some
        > insightful answers to share.

        Me too! :-)

        -Matthew
        azami@...
      • Phil Goodwin
        Pairs produce fewer lines of code per unit time than the same two people would if they were working independently. That code tends to contain a lot fewer bugs
        Message 3 of 8 , Mar 1, 2001
          Pairs produce fewer lines of code per unit time than the same two people
          would if they were working independently.

          That code tends to contain a lot fewer bugs and it does nearly as much.

          My sense of it is that there is a net loss to the number of features and a
          net gain to the level of quality. I haven't done it myself on a long term
          basis so I have mostly anecdotal evidence. I have heard, however, that
          people who are really good at pairing feel that they actually can implement
          features faster if they work in pairs than they can if they work in
          parallel. If that is the case then pairs are clearly more productive.

          Fewer code bases mean a smaller number of integrations. Integration is only
          hard if there are collisions. Integrating frequently reduces the number of
          possible collisions.

          Refactor mercilessly, integrate frequently. The better the code gets the
          more likely it is that changes will be localized.

          ------------------------------------------------------------------------------------------------------------
          Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

          "If everything you try works, you aren't trying hard enough." -- Gordon Moore
        • peter@vanrooijen.com
          [pairs produce higer quality code] I agree with that, and I would agree that higher overall quality reduces overall integration effort. ... How does having
          Message 4 of 8 , Mar 1, 2001
            [pairs produce higer quality code]

            I agree with that, and I would agree that higher overall quality
            reduces overall integration effort.

            > Fewer code bases mean a smaller number of integrations.

            How does having fewer code bases imply a reduction in the number of
            integrations? If you integrate after each task completion, it is only
            the number of tasks that determines the number of integrations. The
            number of concurrent change streams has no effect.

            > Integration is only
            > hard if there are collisions. Integrating frequently reduces the
            number of
            > possible collisions.

            Not by itself. It's the reduction of the task size, not the frequency
            of integration, that reduces integration conflicts, which makes
            continuous integration easier. IOW, unless pairing influences task
            size, it doesn't influence the number of integrations.

            Regards,

            Peter van Rooijen
          • Phil Goodwin
            ... Consider what happens when you reduce the number of concurrent change streams to one. That reduces the number of integrations to zero. Someone else noted
            Message 5 of 8 , Mar 1, 2001
              At 12:57 AM 3/2/01 +0000, you wrote:
              >[pairs produce higer quality code]
              >
              >I agree with that, and I would agree that higher overall quality
              >reduces overall integration effort.
              >
              > > Fewer code bases mean a smaller number of integrations.
              >
              >How does having fewer code bases imply a reduction in the number of
              >integrations? If you integrate after each task completion, it is only
              >the number of tasks that determines the number of integrations. The
              >number of concurrent change streams has no effect.

              Consider what happens when you reduce the number of concurrent change
              streams to one. That reduces the number of "integrations" to zero. Someone
              else noted that the cost of integration has to do with the number of
              conflicts which is correct. It is the conflicts that make the difference
              between integration and simply adding new features. The number of change
              streams directly affects the chances of conflict.


              > > Integration is only
              > > hard if there are collisions. Integrating frequently reduces the
              >number of
              > > possible collisions.
              >
              >Not by itself. It's the reduction of the task size, not the frequency
              >of integration, that reduces integration conflicts, which makes
              >continuous integration easier. IOW, unless pairing influences task
              >size, it doesn't influence the number of integrations.

              Let's consider what happens during integration. You have three code bases:
              the original, the code base from one team and the code base from a second
              team. We are concerned with the deltas between the new code bases and the
              original. Presumably smaller deltas mean a smaller chance of collision. If
              teams integrate frequently then the size of their deltas shrinks thus
              reducing the chance of collision. Keep in mind that after integration the
              size of your delta is zero.



              ------------------------------------------------------------------------------------------------------------
              Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

              "If everything you try works, you aren't trying hard enough." -- Gordon Moore
            • Ron Jeffries
              ... If the code base is 10 classes, it can be a problem. After a few iterations, it isn t a problem any more, because you have lots of classes and don t step
              Message 6 of 8 , Mar 1, 2001
                At 09:58 PM 3/1/2001 +0000, it seemed like peter@... wrote:
                >If it is my duty to refactor at every opportunity I see to improve
                >code, and I can change all the code, and my pair refactors a lot
                >during the completion of a task, as do my fellow pairs:
                >
                >- isn't integration going to be extremely complicated? I mean, we
                >worked adding to and refactoring a code base that has has been
                >updated by an average of 2 other pairs (assume 5 pairs) before we get
                >to integrate our new stuff.

                If the code base is 10 classes, it can be a problem. After a few
                iterations, it isn't a problem any more, because you have lots of classes
                and don't step on each other much. And anyway, integration isn't all that
                hard when you do it one stream at a time.

                >- what do we do about the tests that we changed, because others have
                >changed tests as well. We can easily achieve 100% test success after
                >integrating if we don't actually integrate, but throw away what the
                >others have put in before us. How do we go about deciding which tests
                >we need to have running at 100% after the integration?

                All the tests that were there, plus all the tests you added. Rarely does
                one remove tests unless one removes the corresponding code.

                Ronald E Jeffries
                http://www.XProgramming.com
                http://www.objectmentor.com
              • Robert Sartin
                ... There seem to be a false assumption that integration effort after each task completion is independent of how many tasks were completed between the baseline
                Message 7 of 8 , Mar 1, 2001
                  --- peter@... wrote:
                  > How does having fewer code bases imply a reduction in the number of
                  > integrations? If you integrate after each task completion, it is only
                  > the number of tasks that determines the number of integrations. The
                  > number of concurrent change streams has no effect.

                  There seem to be a false assumption that integration effort after each
                  task completion is independent of how many tasks were completed between
                  the baseline of the task start and the integration point. In real life,
                  the more changes that have occurred (and themselves been integrated)
                  since the baseline, the larger the integration effort. That is why
                  continuous integration works. Pairing helps because it makes tasks
                  temporally shorter (about 60% as long apparently) for the same amount
                  of work, but it also reduces the number of things that have happened to
                  the baseline RELATIVE to the SAME NUMBER of people NOT PAIRING (pardon
                  my shouting, but those are important assumptions in themselves and are
                  the ones implicit in an argument that pairing alone decrease
                  integration). Number of concurrent tasks does matter because it affects
                  the number of changes that will have been made to the baseline of the
                  task being integrated.

                  Regards,

                  Rob


                  __________________________________________________
                  Do You Yahoo!?
                  Get email at your own domain with Yahoo! Mail.
                  http://personal.mail.yahoo.com/
                • Ron Jeffries
                  ... This is definitely true for me. I tire less when pairing, do better work, have more fun, and unquestionably get more done. Whether I m good at it or not.
                  Message 8 of 8 , Mar 1, 2001
                    At 04:30 PM 3/1/2001 -0800, it seemed like Phil Goodwin wrote:
                    >I have heard, however, that
                    >people who are really good at pairing feel that they actually can implement
                    >features faster if they work in pairs than they can if they work in
                    >parallel. If that is the case then pairs are clearly more productive.

                    This is definitely true for me. I tire less when pairing, do better work,
                    have more fun, and unquestionably get more done. Whether I'm good at it or
                    not. ;->

                    Ronald E Jeffries
                    http://www.XProgramming.com
                    http://www.objectmentor.com
                  Your message has been successfully submitted and would be delivered to recipients shortly.