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

Re: [XP] Re: Starting XP from scratch

Expand Messages
  • 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 1 of 19 , Feb 1, 2001
    • 0 Attachment
      At 01:18 PM 2/1/2001 +0000, it seemed like ggoldstein@... wrote:
      > > Never branch the repository.
      >
      >Hmm, I'm not sure about this one. Here's what's worked for us ...
      >
      >At the end of an iteration we immediately tag the mainline (we're
      >using CVS -- I've got mixed feelings about it but it's OK) and build
      >a Production branch. During the next iteration all work is done on
      >the mainline (all enhancements are ALWAYS done on the mainline) but
      >any critical bug fixes that have to get to Production ASAP or any
      >code-independent content changes are done on the Production branch.
      >This allows us to push code to production without pulling along the
      >work currently being done for the iteration.

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

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

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

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

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

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


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

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

      Regards,



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

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

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

        Each of these steps provides a very important element:

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

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

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

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

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

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

        Regards,

        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com
      • Matthew Kleiderman
        ... than not ... badly but ... to old ... Actually, it s pretty close to a new team. There are two people here who have done maintenance on the old code, two
        Message 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.