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

Re: [XP] Starting XP from scratch

Expand Messages
  • Ron Jeffries
    ... The practices each take ... well ... practice. There s no real reason IMO not to start doing them all at once if you have the inclination, but expect that
    Message 1 of 19 , Jan 31, 2001
    • 0 Attachment
      At 03:56 PM 1/31/2001 -0500, it seemed like Matt Kleiderman wrote:
      >So, in short, it seems like an extremely fertile field for me to try and
      >plant all the XP practices in. The books suggest an incremental rollout of
      >the practices, but they seem more oriented towards established organizations
      >with some momentum. So I'm tempted to try and implement all the practices
      >at once. Are there some known reasons for avoiding this that I've missed in
      >my reading, or other things to keep my eye on if I continue down this path?

      The practices each take ... well ... practice. There's no real reason IMO
      not to start doing them all at once if you have the inclination, but expect
      that you'll have to shake them out.

      I'd push really hard on test-first programming and making the unit tests
      run at 100% ALL the time. Release code really often -- twice a day per
      pair. Build the entire system each time you release code, and run all the
      unit tests. Everyone reload from the repository as soon as possible after
      each code release. Never ever keep anything checked out overnight. Never
      branch the repository.

      Keep the code unbelievably clean -- it's hard to catch up on refactoring.

      Insist on having automated acceptance tests for every story. Accept no
      substitutes, they are your safety net for when your inexperience with unit
      testing lets you down.

      Do your planning games religiously, both release and iteration. In
      iteration planning be sure to break everything down to the task level and
      have the person who does the task estimate it. Check your estimates against
      reality and reflect as to what went wrong. Reestimate the stories from time
      to time.

      And keep us posted and ask questions when things seem odd.

      Good luck!

      Ronald E Jeffries
      http://www.XProgramming.com
      http://www.objectmentor.com
    • Don Wells
      Even though you may be throwing away the code you are presumably not throwing away the people. The condition of your code more often than not reflects the
      Message 2 of 19 , Jan 31, 2001
      • 0 Attachment
        Even though you may be throwing away the code you are presumably not
        throwing away the people. The condition of your code more often than not
        reflects the condition of your team. They may want change very badly but
        when it comes time to actually do XP they might balk and revert back to old
        habits. Do not assume it will be just plug and play. They may not be ready
        to have all of XP dumped on them or maybe they might, only you know for
        sure. The good news is they will tell you one way or another as you
        introduce it. Just talking about it isn't the same.

        Before you throw away that old code you should do your best to learn
        everything it has to teach you about your problem. In more concrete terms:
        Can you write automated acceptance tests for the old code now and run them
        against the new code when it is finished? Can you use the old system to
        create test data for the new system? Think about what else you can get from
        the old system before you toss it because you are also tossing the teams
        ability to deal with it. Once the team is free and clear of that albatross
        no one will want to go back to it for salvage purposes. Save what you can
        now, then throw it away and never look back.

        Don Wells

        -----Original Message-----
        From: Matt Kleiderman <mattk@...>
        To: 'extremeprogramming@yahoogroups.com'
        <extremeprogramming@yahoogroups.com>
        Date: Wednesday, January 31, 2001 4:20 PM
        Subject: [XP] Starting XP from scratch


        >Well, I've just finished digesting XPE, PXP and XPI, and lurking on this
        >list for a couple of weeks. I'm starting on a project which seems
        >well-suited for XP. It involves scrapping every line of code in an
        existing
        >application and rewriting from the ground up, moving from C++ to Java in
        the
        >process. The current development team wants nothing more than to burn the
        >old code and do everything different (they were burned but bad) and seem
        >excited by my presenting of XP and its ideas and practices. I've been
        >talking with Product Management and QA and they're also interested, and
        want
        >the old ways to change radically.
        >
        >So, in short, it seems like an extremely fertile field for me to try and
        >plant all the XP practices in. The books suggest an incremental rollout of
        >the practices, but they seem more oriented towards established
        organizations
        >with some momentum. So I'm tempted to try and implement all the practices
        >at once. Are there some known reasons for avoiding this that I've missed
        in
        >my reading, or other things to keep my eye on if I continue down this path?
        >
        >Thanks,
        >
        >Matt Kleiderman
        >mattk@...
        >Principal Software Architect
        >PfN, Inc.
        >26 Landsdowne St.
        >Cambridge, MA 02139
        >617-679-0261
        >
        >
        >
        >[Non-text portions of this message have been removed]
        >
        >
        >To Post a message, send it to: extremeprogramming@...
        >
        >To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...
        >
        >Ad-free courtesy of objectmentor.com
        >
        >
      • ggoldstein@ibelong.com
        Matt: Down the street here in Waltham we faced the same situation and about five months ago rewrote our core application in Java and used XP as our methodolgy.
        Message 3 of 19 , Feb 1, 2001
        • 0 Attachment
          Matt:

          Down the street here in Waltham we faced the same situation and about
          five months ago rewrote our core application in Java and used XP as
          our methodolgy. I have a couple of comments to add to the good
          advice Ron gave:

          > I'd push really hard on test-first programming and making the unit
          tests run at 100% ALL the time.

          Absolutely critical. You'll need a framework for this -- JUnit
          worked well for us. The biggest issue is getting your developer to
          buy into this. Not only do you need unit test but you need tests
          that are written to test anything that could possibly break.
          Everyone's onboard now but originally we had some conversations along
          the lines of, "Why test for that being null when I can see that the
          column is defined as NOT NULL in the database?"

          > Never branch the repository.

          Hmm, I'm not sure about this one. Here's what's worked for us ...

          At the end of an iteration we immediately tag the mainline (we're
          using CVS -- I've got mixed feelings about it but it's OK) and build
          a Production branch. During the next iteration all work is done on
          the mainline (all enhancements are ALWAYS done on the mainline) but
          any critical bug fixes that have to get to Production ASAP or any
          code-independent content changes are done on the Production branch.
          This allows us to push code to production without pulling along the
          work currently being done for the iteration.

          We've also found that dedicating one person each iteration to bugs
          works well. The developers rotate through this role and generally
          learn a lot about the system and what can break which makes them
          better programmers.

          Any of the changes made on the Production branch are joined back to
          the mainline as frequently as possible.

          > Do your planning games religiously, both release and iteration...

          We've found that doing group tasking as described in one of the XP
          books (Planning XP?) was a great idea. Originally we would have an
          individual developer task out a user story. We found that our
          estimates weren't very accurate primarily because we didn't
          understand related tasks which involved the web designers/developers
          or operations.

          Now we still do those initial estimates and use those to hold the
          planning game. Immediately afterwards we gather the customers, web
          developers, web designers, java developers, SQL developers, QA, and
          operations in a room with white boards to retask the user stories
          that were selected. We've found that these estimates are very
          accurate, result in better designs, allow everyone to feel included
          in the design process. If our estimates change as the result of this
          process (sometimes they're even shorter) then we do a quick planning
          game to ensure that we're being honest with ourselves about what we
          can accomplish during the iteration.

          Anyway, I hope that is helpful.



          --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
          > At 03:56 PM 1/31/2001 -0500, it seemed like Matt Kleiderman wrote:
          > >So, in short, it seems like an extremely fertile field for me to
          try and
          > >plant all the XP practices in. The books suggest an incremental
          rollout of
          > >the practices, but they seem more oriented towards established
          organizations
          > >with some momentum. So I'm tempted to try and implement all the
          practices
          > >at once. Are there some known reasons for avoiding this that I've
          missed in
          > >my reading, or other things to keep my eye on if I continue down
          this path?
          >
          > The practices each take ... well ... practice. There's no real
          reason IMO
          > not to start doing them all at once if you have the inclination,
          but expect
          > that you'll have to shake them out.
          >
          > I'd push really hard on test-first programming and making the unit
          tests
          > run at 100% ALL the time. Release code really often -- twice a day
          per
          > pair. Build the entire system each time you release code, and run
          all the
          > unit tests. Everyone reload from the repository as soon as possible
          after
          > each code release. Never ever keep anything checked out overnight.
          Never
          > branch the repository.
          >
          > Keep the code unbelievably clean -- it's hard to catch up on
          refactoring.
          >
          > Insist on having automated acceptance tests for every story. Accept
          no
          > substitutes, they are your safety net for when your inexperience
          with unit
          > testing lets you down.
          >
          > Do your planning games religiously, both release and iteration. In
          > iteration planning be sure to break everything down to the task
          level and
          > have the person who does the task estimate it. Check your estimates
          against
          > reality and reflect as to what went wrong. Reestimate the stories
          from time
          > to time.
          >
          > And keep us posted and ask questions when things seem odd.
          >
          > Good luck!
          >
          > Ronald E Jeffries
          > http://www.XProgramming.com
          > http://www.objectmentor.com
        • Ron Jeffries
          ... Are you running all your unit tests at 100% for every code push? If so, what would be wrong with pulling along partially done work? ... But seriously ...
          Message 4 of 19 , Feb 1, 2001
          • 0 Attachment
            At 01:18 PM 2/1/2001 +0000, it seemed like ggoldstein@... wrote:
            > > Never branch the repository.
            >
            >Hmm, I'm not sure about this one. Here's what's worked for us ...
            >
            >At the end of an iteration we immediately tag the mainline (we're
            >using CVS -- I've got mixed feelings about it but it's OK) and build
            >a Production branch. During the next iteration all work is done on
            >the mainline (all enhancements are ALWAYS done on the mainline) but
            >any critical bug fixes that have to get to Production ASAP or any
            >code-independent content changes are done on the Production branch.
            >This allows us to push code to production without pulling along the
            >work currently being done for the iteration.

            Are you running all your unit tests at 100% for every code push? If so,
            what would be wrong with pulling along partially done work?

            >We've also found that dedicating one person each iteration to bugs
            >works well. The developers rotate through this role and generally
            >learn a lot about the system and what can break which makes them
            >better programmers.

            But seriously ... why are there so many defects that you have to dedicate a
            person to them? One person is what percent of your time? Do you write a
            test to show every defect before fixing it? Are you beefing up the rest of
            the tests every time you find a defect?

            There's only one good size for a bug list. No, really. I'm serious, you can
            do it.

            >Any of the changes made on the Production branch are joined back to
            >the mainline as frequently as possible.

            Isn't merging the changes kind of a pain? What would it take to have only
            one branch?


            (See why nobody likes me? I'm never satisfied.)

            You're doing well ... keep it up. But careful, next thing you know you'll
            have a bug database ...

            Regards,



            Ronald E Jeffries
            http://www.XProgramming.com
            http://www.objectmentor.com
          • Ron Jeffries
            ... Good. To clarify, Iteration Planning should IMO contain three steps: 1. Customer explains stories; 2. Team brainstorms tasks; 3. Each programmer signs up
            Message 5 of 19 , Feb 1, 2001
            • 0 Attachment
              At 01:18 PM 2/1/2001 +0000, it seemed like ggoldstein@... wrote:
              >We've found that doing group tasking as described in one of the XP
              >books (Planning XP?) was a great idea. Originally we would have an
              >individual developer task out a user story. We found that our
              >estimates weren't very accurate primarily because we didn't
              >understand related tasks which involved the web designers/developers
              >or operations.
              >
              >Now we still do those initial estimates and use those to hold the
              >planning game. Immediately afterwards we gather the customers, web
              >developers, web designers, java developers, SQL developers, QA, and
              >operations in a room with white boards to retask the user stories
              >that were selected. We've found that these estimates are very
              >accurate, result in better designs, allow everyone to feel included
              >in the design process. If our estimates change as the result of this
              >process (sometimes they're even shorter) then we do a quick planning
              >game to ensure that we're being honest with ourselves about what we
              >can accomplish during the iteration.

              Good. To clarify, Iteration Planning should IMO contain three steps:

              1. Customer explains stories;
              2. Team brainstorms tasks;
              3. Each programmer signs up and estimates tasks.

              Each of these steps provides a very important element:

              1. "Customer explains stories" is analysis. The programmers find out what
              is needed and increase their understanding of the need. This step should
              include definition of the Acceptance Tests for each story. (*)

              2. "Team brainstorms tasks" is design. Everyone gets to help with the
              design, and everyone learns about the whole system design, not just the
              parts they do. This step should probably consist of just making a list of
              tasks, with any actual CRC or UML discussions deferred. But do have those
              discussions as needed for quality or communication. See Quick Design
              Session in XPI.

              3. "Each programmer signs up and estimates tasks" provides individual
              estimates, individual commitment, and an opportunity for each programmer to
              improve estimation. Each programmer should consider her performance against
              estimates last time around.

              Anyway ... that's how I'd suggest you go about iteration planning.

              * Acceptance Tests are how you know you are done and ready to release. If
              defects are being put into the delivered product, and you're not doing
              Acceptance Tests for every story ... well, you know what I'm going to say next.

              And if you ARE doing ATs and defects are being put in ... oh, you know.

              Regards,

              Ronald E Jeffries
              http://www.XProgramming.com
              http://www.objectmentor.com
            • Matthew Kleiderman
              ... than not ... badly but ... to old ... Actually, it s pretty close to a new team. There are two people here who have done maintenance on the old code, two
              Message 6 of 19 , Feb 1, 2001
              • 0 Attachment
                --- In extremeprogramming@y..., "Don Wells" <xplist@e...> wrote:
                > Even though you may be throwing away the code you are presumably not
                > throwing away the people. The condition of your code more often
                than not
                > reflects the condition of your team. They may want change very
                badly but
                > when it comes time to actually do XP they might balk and revert back
                to old
                > habits.

                Actually, it's pretty close to a new team. There are two people here
                who have done maintenance on the old code, two who haven't touched it,
                and I need to go out and find a few more. No one who did the original
                design and development is left. The condition of the team is
                well-described by fatigued from working with the old stuff. The
                condition of the old code.... well, I just ran across an 8-page
                method yesterday. I'll leave it at that.

                > Do not assume it will be just plug and play. They may not
                be ready
                > to have all of XP dumped on them or maybe they might, only you know
                for
                > sure. The good news is they will tell you one way or another as you
                > introduce it. Just talking about it isn't the same.
                >
                > Before you throw away that old code you should do your best to learn
                > everything it has to teach you about your problem. In more concrete
                terms:
                > Can you write automated acceptance tests for the old code now and
                run them
                > against the new code when it is finished? Can you use the old
                system to
                > create test data for the new system? Think about what else you can
                get from
                > the old system before you toss it because you are also tossing the
                teams
                > ability to deal with it. Once the team is free and clear of that
                albatross
                > no one will want to go back to it for salvage purposes. Save what
                you can
                > now, then throw it away and never look back.
                >
                > Don Wells
                >

                This is interesting, I've been looking at this in a slightly different
                way. We have largely intact QA and Support organizations who can give
                me volumes of stories about life with the old codebase, and what they
                learned working with it for years. I'll give some more thought to
                uses for actual code. It might be useful for automated acceptance
                testing.

                Thanks,
                Matt Kleiderman
              • Matthew Kleiderman
                ... dedicate a ... write a ... rest of ... you can ... I ve got to say, that one tweak I m considering as my personal safety blanket is not work on any user
                Message 7 of 19 , Feb 1, 2001
                • 0 Attachment
                  > >We've also found that dedicating one person each iteration to bugs
                  > >works well. The developers rotate through this role and generally
                  > >learn a lot about the system and what can break which makes them
                  > >better programmers.
                  >
                  > But seriously ... why are there so many defects that you have to
                  dedicate a
                  > person to them? One person is what percent of your time? Do you
                  write a
                  > test to show every defect before fixing it? Are you beefing up the
                  rest of
                  > the tests every time you find a defect?
                  >
                  > There's only one good size for a bug list. No, really. I'm serious,
                  you can
                  > do it.
                  >

                  I've got to say, that one tweak I'm considering as my personal safety
                  blanket is not work on any user stories one iteration in four, and
                  just spend the time refactoring and satisfying any acceptance tests we
                  might have missed. I'm not expecting to branch the repository then
                  (it will be the iteration before the release). I'm also hoping it
                  will be an extremely boring iteration that I might just declare over
                  before it's time is over. But it leaves me feeling warm and
                  secure, knowing I've got a chance to recover from my initial crappy
                  estimates.

                  Matt Kleiderman
                  mattk@...
                  Principal Software Architect
                  PfN, Inc.
                  26 Landsdowne St
                  Cambridge, MA 02139
                  617-679-0261
                • ggoldstein@ibelong.com
                  ... so, ... To be honest our unit test coverage is not what it should be. But even if it was 100% we still might not want to push new functionality into
                  Message 8 of 19 , Feb 3, 2001
                  • 0 Attachment
                    --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                    > At 01:18 PM 2/1/2001 +0000, it seemed like ggoldstein@i... wrote:
                    > > > Never branch the repository.
                    > >
                    >
                    > Are you running all your unit tests at 100% for every code push? If
                    so,
                    > what would be wrong with pulling along partially done work?

                    To be honest our unit test coverage is not what it should be. But
                    even if it was 100% we still might not want to push new functionality
                    into Production before the customer is ready for it.


                    > But seriously ... why are there so many defects that you have to
                    dedicate a
                    > person to them? One person is what percent of your time? Do you
                    write a
                    > test to show every defect before fixing it? Are you beefing up the
                    rest of
                    > the tests every time you find a defect?
                    >
                    > There's only one good size for a bug list. No, really. I'm serious,
                    you can
                    > do it.

                    I can't argue with you here. However most of the "bugs" are really
                    time-critical enhancements for customers outside the scope of our
                    normal iterations. Since people are paying for these it seemed best
                    to accept this as a reality and dedicate one person to supporting
                    this, fixing real bugs (which are mostly due to not having enough
                    tests as you've pointed out), and refactoring and catching up on
                    adding tests we've neglected to get right the first time.


                    > >Any of the changes made on the Production branch are joined back to
                    > >the mainline as frequently as possible.
                    >
                    > Isn't merging the changes kind of a pain? What would it take to
                    have only
                    > one branch?

                    Merging changes back is not a problem once you get the hang of it.
                    We do only have one branch; there's the mainline (think of this as
                    the "trunk") and one branch which is identical to the code in the
                    trunk just before the start of the current iteration. This has
                    worked quite well but in a perfect world where you've earned the XP
                    Seal of Approval it's probably overkill.

                    > (See why nobody likes me? I'm never satisfied.)
                    >
                    > You're doing well ... keep it up. But careful, next thing you know
                    you'll
                    > have a bug database ...

                    Well, we've found that the more XP we get the better things work.
                    We're now working with XP for a number of parallel projects in 3
                    different offices both here and in India.

                    Thanks for the advice.
                  • Jim Little
                    From: Ron Jeffries ... We do this -- that is, we run the tests at 100% and deploy partially-done work. (Note: I m not the person Ron
                    Message 9 of 19 , Feb 5, 2001
                    • 0 Attachment
                      From: "Ron Jeffries" <ronjeffries@...>
                      > Are you running all your unit tests at 100% for every code push? If so,
                      > what would be wrong with pulling along partially done work?

                      We do this -- that is, we run the tests at 100% and deploy partially-done
                      work. (Note: I'm not the person Ron is replying to.) It has worked well
                      for us, for the most part, in that it has allowed us to work with a very
                      simple revision control / build structure. Bugs haven't been a problem with
                      this -- just yesterday our "support swami" fixed a bug by checking out the
                      latest (100% passing tests) code from the repository, fixing it
                      (test-first), and checking the code back in. We have a rule that a check-in
                      isn't done until it's been checked out on our integration box and all the
                      tests have passed. Users don't notice that the work is partially done
                      because we don't hook those pieces up to the UI until they're ready.

                      The one area where not using branching was a little weird was when we
                      recently made major changes to a deployed part of the system. Last
                      iteration we did that. Rather than branching, we copied the code to a
                      "phase2" subdirectory and made the changes there. Sort of a poor-man's
                      branch, but it worked.

                      Jim
                    • Charles Medcoff
                      ... This makes sense, but I have a dumb question. How do you get the code from a development workstation onto the integration machine without checking into
                      Message 10 of 19 , Feb 14, 2001
                      • 0 Attachment
                        > We have a rule that a check-in isn't done until it's been checked
                        > out on our integration box and all the tests have passed.

                        This makes sense, but I have a dumb question. How do you get the
                        code from a development workstation onto the integration machine
                        without checking into the repository?
                      • David Corbin
                        ... That s one I ve asked before too. The best response (and it was so-so) was that each pair works on a branch, committing to the branch on their work
                        Message 11 of 19 , Feb 15, 2001
                        • 0 Attachment
                          Charles Medcoff wrote:
                          >
                          > > We have a rule that a check-in isn't done until it's been checked
                          > > out on our integration box and all the tests have passed.
                          >
                          > This makes sense, but I have a dumb question. How do you get the
                          > code from a development workstation onto the integration machine
                          > without checking into the repository?

                          That's one I've asked before too. The best response (and it was so-so)
                          was that each pair works on a branch, committing to the branch on their
                          work machine, and the branch gets merged into the mainline on the
                          integration machine.

                          --
                          David Corbin
                          dcorbin@...
                        • Ron Jeffries
                          ... Depends on your code manager. Envy let you put things in the repository and commit them to the mainline as separate steps. Making a branch for a couple of
                          Message 12 of 19 , Feb 15, 2001
                          • 0 Attachment
                            At 06:21 AM 2/15/2001 -0500, it seemed like David Corbin wrote:
                            > > This makes sense, but I have a dumb question. How do you get the
                            > > code from a development workstation onto the integration machine
                            > > without checking into the repository?
                            >
                            >That's one I've asked before too. The best response (and it was so-so)
                            >was that each pair works on a branch, committing to the branch on their
                            >work machine, and the branch gets merged into the mainline on the
                            >integration machine.

                            Depends on your code manager. Envy let you put things in the repository and
                            commit them to the mainline as separate steps. Making a branch for a couple
                            of hours and then merging it back seems OK to me ... why does that seem bad?

                            And why not just copy the files from your machine to the integration machine?

                            Finally, there is no need to have an integration machine if your code
                            management or network make it difficult. There are at least two sub-options ...

                            1. use some other integration token ... open a file for write on a specific
                            machine, so that no one else can get the file, or wear a funny hat.

                            2. just take chances that you'll get more than one team's files when you
                            merge, and deal with it.

                            I don't like option 2, as it seems to me that it leads to extra debugging
                            and will discourage frequent integration. But try it if it seems good to
                            you. Thoughtworks basically does this and report it works for them.
                            Thoughtworks guys? Tell us about it?



                            Ronald E Jeffries
                            http://www.XProgramming.com
                            http://www.objectmentor.com
                          • Ron Jeffries
                            Sunday evening through Tuesday, a number of luminaries in the realm of agile software development process met in Snowbird. I was also present. We had something
                            Message 13 of 19 , Feb 15, 2001
                            • 0 Attachment
                              Sunday evening through Tuesday, a number of luminaries in the realm of
                              agile software development process met in Snowbird. I was also present.

                              We had something like 17 people, and processes represented included
                              Adaptive Software Development, Crystal, SCRUM, DSDM, and XP.

                              Many issues were discussed, and the group had a good time and found that
                              their ideas were generally quite compatible. We prepared a "manifesto", a
                              statement we could all sign, addressed to the industry, describing the
                              values and practices that make up the common elements of what we decided to
                              call "agile" software development processes. We expect to have the
                              manifesto wordsmithed and released within about four weeks.

                              The meeting was fun, the snow was good according to those who went out in
                              it. Alistair Cockburn checked it out extensively, even performing a face
                              plant for an intimate look at snow quality.

                              Those of us from the plains were fascinated to discover that there is no
                              oxygen in the air at 8000 feet, but that somehow life has managed to
                              survive there.

                              "Nature will find a way." -- Ian Malcolm (http://www.santafe.edu/~malcolm/ )

                              Ronald E Jeffries
                              http://www.XProgramming.com
                              http://www.objectmentor.com
                            • David Corbin
                              ... Well, depending on your source-control system, branches can be a real bear. I use Perforce, which isn t too bad about them, but it s still not as natural
                              Message 14 of 19 , Feb 15, 2001
                              • 0 Attachment
                                Ron Jeffries wrote:
                                >
                                > At 06:21 AM 2/15/2001 -0500, it seemed like David Corbin wrote:
                                > > > This makes sense, but I have a dumb question. How do you get the
                                > > > code from a development workstation onto the integration machine
                                > > > without checking into the repository?
                                > >
                                > >That's one I've asked before too. The best response (and it was so-so)
                                > >was that each pair works on a branch, committing to the branch on their
                                > >work machine, and the branch gets merged into the mainline on the
                                > >integration machine.
                                >
                                > Depends on your code manager. Envy let you put things in the repository and
                                > commit them to the mainline as separate steps. Making a branch for a couple
                                > of hours and then merging it back seems OK to me ... why does that seem bad?

                                Well, depending on your source-control system, branches can be a real
                                bear. I use Perforce, which isn't too bad about them, but it's still
                                not as natural as just submitting directly into the mainline.

                                >
                                > And why not just copy the files from your machine to the integration machine?

                                Won't work with Perforce. Perforce keeps of track of what files on what
                                machines are "checked-out for edit". While it would be possible to get
                                around this, it would be really awkward, and I don't generally recommend
                                circumventing the source-control-system.

                                >
                                > Finally, there is no need to have an integration machine if your code
                                > management or network make it difficult. There are at least two sub-options ...
                                >
                                > 1. use some other integration token ... open a file for write on a specific
                                > machine, so that no one else can get the file, or wear a funny hat.
                                >

                                sounds fine to me.

                                > 2. just take chances that you'll get more than one team's files when you
                                > merge, and deal with it.
                                >

                                I'm not sure how having an integration machine or token prevents you
                                from getting more than "one team's files" when you merge anyway. I
                                would expect to get all the changes since I last merged my changes.


                                > I don't like option 2, as it seems to me that it leads to extra debugging
                                > and will discourage frequent integration. But try it if it seems good to
                                > you. Thoughtworks basically does this and report it works for them.
                                > Thoughtworks guys? Tell us about it?
                                >
                                > Ronald E Jeffries
                                > http://www.XProgramming.com
                                > http://www.objectmentor.com
                                >
                                > To Post a message, send it to: extremeprogramming@...
                                >
                                > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                >
                                > Ad-free courtesy of objectmentor.com

                                --
                                David Corbin
                                dcorbin@...
                              • Ron Jeffries
                                ... Yes, but if each team integrates serially and runs all the tests, everything you merge in was shown to work correctly when THEY integrated. That means that
                                Message 15 of 19 , Feb 15, 2001
                                • 0 Attachment
                                  At 08:22 AM 2/15/2001 -0500, it seemed like David Corbin wrote:
                                  >I'm not sure how having an integration machine or token prevents you
                                  >from getting more than "one team's files" when you merge anyway. I
                                  >would expect to get all the changes since I last merged my changes.

                                  Yes, but if each team integrates serially and runs all the tests,
                                  everything you merge in was shown to work correctly when THEY integrated.
                                  That means that anything that breaks is due to a change YOU made, and of
                                  course you're familiar with your code changes, so finding the problems is
                                  usually easy.

                                  If two teams integrate at once, with neither's code fully tested in the
                                  integrated version, it's a little less certain whose change broke things.

                                  Either way can work ... personally I prefer single integration, because I
                                  am a bear of very little brain.

                                  Regards,

                                  Ronald E Jeffries
                                  http://www.XProgramming.com
                                  http://www.objectmentor.com
                                • wecaputo@thoughtworks.com
                                  ... Yes (on my project at least) this is how we do it. It can be painful, but the intersection goes down as functionality goes up (and people start working on
                                  Message 16 of 19 , Feb 15, 2001
                                  • 0 Attachment
                                    Ron Jeffries:
                                    >2. just take chances that you'll get more than one team's files when you
                                    >merge, and deal with it.

                                    >I don't like option 2, as it seems to me that it leads to extra debugging
                                    >and will discourage frequent integration. But try it if it seems good to
                                    >you. Thoughtworks basically does this and report it works for them.
                                    >Thoughtworks guys? Tell us about it?

                                    Yes (on my project at least) this is how we do it. It can be painful, but
                                    the intersection goes down as functionality goes up (and people start
                                    working on different parts of the code). I expect it to become a non-event
                                    as the code base grows. Also, we try to stabilize our interfaces quickly if
                                    people are working from a common header file. Changes to interfaces seem to
                                    happen at Iteration beginnings, and then stabilize as people complete their
                                    tasks.

                                    What helps is that we are sitting in the same room -- if someone needs to
                                    merge a file, they can get the person who wrote the changes they are
                                    merging with to help.

                                    Also, we just got our automated build working -- a process monitors the
                                    source repository, and automatically checks out the code, and builds it, so
                                    this should greatly reduce our merge conflicts.

                                    Finally, passing builds are marked in the source repository with a label.
                                    When someone wants the 'latest' version, they just check out the last
                                    labelled version. Thus, only passing code notches us forward.

                                    Our infrastructure is just now coming together for this project, so we
                                    haven't shaken the bugs out yet. Other projects at ThoughtWorks have a more
                                    mature process. Also, we are working in C++ and they are working in Java,
                                    so we are learning differences there as well.

                                    So in short, you can do number 2, but you need more infrastructure to make
                                    it painless(er), so it isn't the simplest thing, but it isn't the starting
                                    point either, we have evolved to this point from simpler beginnings.

                                    Best,
                                    Bill
                                  • mlroyle@thoughtworks.com
                                    ... Experience has shown us that it actually encourages frequent integration. This is because the first one in with that code doesn t have to merge; therefore,
                                    Message 17 of 19 , Feb 15, 2001
                                    • 0 Attachment
                                      >I don't like option 2, as it seems to me that it leads to extra debugging
                                      >and will discourage frequent integration. But try it if it seems good to
                                      >you. Thoughtworks basically does this and report it works for them.
                                      >Thoughtworks guys? Tell us about it?

                                      Experience has shown us that it actually encourages frequent integration.
                                      This is because the first one in with that code doesn't have to merge;
                                      therefore, it is advantageous to work in shorter cycles and integrate often
                                      because it reduces the changes that you'll have to merge at all.

                                      Mike
                                    • Ron Jeffries
                                      ... I can see this, and would hope it d go that way. I ve also seen the reverse happen. People are so ... so ... so human! R Ronald E Jeffries
                                      Message 18 of 19 , Feb 15, 2001
                                      • 0 Attachment
                                        At 01:05 PM 2/15/2001 -0600, it seemed like mlroyle@... wrote:
                                        > >I don't like option 2, as it seems to me that it leads to extra debugging
                                        > >and will discourage frequent integration. But try it if it seems good to
                                        > >you. Thoughtworks basically does this and report it works for them.
                                        > >Thoughtworks guys? Tell us about it?
                                        >
                                        >Experience has shown us that it actually encourages frequent integration.
                                        >This is because the first one in with that code doesn't have to merge;
                                        >therefore, it is advantageous to work in shorter cycles and integrate often
                                        >because it reduces the changes that you'll have to merge at all.

                                        I can see this, and would hope it'd go that way. I've also seen the reverse
                                        happen. People are so ... so ... so human!

                                        R



                                        Ronald E Jeffries
                                        http://www.XProgramming.com
                                        http://www.objectmentor.com
                                      • Roger Lipscombe
                                        ... sub-options ... ... specific ... If we re doing wide-ranging changes to the repository (such as a merge of changes from a maintenance branch onto the
                                        Message 19 of 19 , Feb 16, 2001
                                        • 0 Attachment
                                          Ron Jeffries wrote:
                                          > Finally, there is no need to have an integration machine if your code
                                          > management or network make it difficult. There are at least two
                                          sub-options ...
                                          >
                                          > 1. use some other integration token ... open a file for write on a
                                          specific
                                          > machine, so that no one else can get the file, or wear a funny hat.

                                          If we're doing wide-ranging changes to the repository (such as a merge of
                                          changes from a maintenance branch onto the trunk), we do this. We don't
                                          have a token as such -- whoever's doing it just shouts "hands off CVS".

                                          > 2. just take chances that you'll get more than one team's files when you
                                          > merge, and deal with it.
                                          >
                                          > I don't like option 2, as it seems to me that it leads to extra debugging
                                          > and will discourage frequent integration. But try it if it seems good to
                                          > you.

                                          For me, it encourages quicker integration - if I can get my changes into the
                                          mainline before anyone else checks anything in, they get hit with the
                                          conflicts. Mwahahahaha.

                                          Seriously, though. We use CVS in a team of 8 people, and constantly
                                          branching and merging feels odd, error-prone even (probably due to lack of
                                          experience with this part of CVS).

                                          We've never found it a problem to simply update our copy of the code, deal
                                          with any conflicts, run the tests locally; and then check the whole shebang
                                          back in. If we find that another pair's changes have broken what we've been
                                          working on, we grab one of them for a couple of minutes.

                                          There's a window for overlap, but it's not yet been a problem for us.

                                          The other problem that I've experienced with branches is that it
                                          _discourages_ frequent integration. If I've branched the code to hack on
                                          something for a day or two, I'm more reluctant to do frequent merges. This
                                          may be because I'm not familiar enough with doing them in CVS.

                                          Cheers,
                                          Roger.
                                        Your message has been successfully submitted and would be delivered to recipients shortly.