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

Re: Starting XP from scratch

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.