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

Re: Starting XP from scratch

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