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

Re: Starting XP from scratch

Expand Messages
  • 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 1 of 19 , Feb 1, 2001
      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 2 of 19 , Feb 1, 2001
        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 3 of 19 , Feb 1, 2001
          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 4 of 19 , Feb 1, 2001
            --- 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 5 of 19 , Feb 1, 2001
              > >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 6 of 19 , Feb 3, 2001
                --- 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 7 of 19 , Feb 5, 2001
                  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 8 of 19 , Feb 14, 2001
                    > 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 9 of 19 , Feb 15, 2001
                      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 10 of 19 , Feb 15, 2001
                        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 11 of 19 , Feb 15, 2001
                          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 12 of 19 , Feb 15, 2001
                            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 13 of 19 , Feb 15, 2001
                              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 14 of 19 , Feb 15, 2001
                                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 15 of 19 , Feb 15, 2001
                                  >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 16 of 19 , Feb 15, 2001
                                    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 17 of 19 , Feb 16, 2001
                                      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.