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

Re: [XP] Prerequisites of CI

Expand Messages
  • Jay Flowers
    ... Yes and yes. ... No, that would be rude. The dissemination of the information you list is what I am after, and in some cases more or less. A CruiseControl
    Message 1 of 13 , Nov 3, 2005
    • 0 Attachment
      > By "introduce a change" do you mean "commit" your changes to the
      > codeline that the rest of the team is using as the basis of their own
      > changes (and what they must integrate with before they commit their own
      > changes)? If so, it seems as if youre saying that if my change "breaks
      > the build" it should inform everyone very quickly. Is that what you
      > mean?

      Yes and yes.

      > Are you assuming an environment where I knowingly allow my change
      > to break the build?

      No, that would be rude.

      The dissemination of the information you list is what I am after, and
      in some cases more or less. A CruiseControl web site and its other
      means of publication are great for this.

      I have read the paper on Continuous Coordination I thought it was a
      great idea. I think it ties in with Micheal Feathers statements about
      Lag Time in "Working Effectively with Legacy Code".
      <quote>Changes often take a long time for another very common reason:
      lag time. Lag time is the amount of time that passes between a change
      that you make and the moment that you get real feedback about the
      change.</quote>

      The context for this statement is for an individual but Continuous
      Coordination is about broadening the scope to the entire dev team.

      Anyway thanks for the additional resources I will assimilate them. :)

      On 11/3/05, Brad Appleton <bradpro@...> wrote:
      > Jay Flowers wrote:
      > > When I introduce the change I should be inform quickly if the change
      > > breaks anything and if it does what it broke so that I can fix it.
      > > So I need to explain quick and inform now. By quick I mean I don't
      > > want to loose flow before the I have to fix something. By inform I
      > > mean I want to know what method of what class is not behaving in the
      > > expected way.
      >
      > By "introduce a change" do you mean "commit" your changes to the
      > codeline that the rest of the team is using as the basis of their own
      > changes (and what they must integrate with before they commit their own
      > changes)? If so, it seems as if youre saying that if my change "breaks
      > the build" it should inform everyone very quickly. Is that what you
      > mean? Are you assuming an environment where I knowingly allow my change
      > to break the build?
      >
      > Im trying to figure out if what you are after is some kind of
      > post-commit notification that gets logged to a team webpage/blog or
      > maillist?
      >
      > Or if what you are after is some kind of basic version-control codeline
      > status reporting (sort of like a "burndown" chart, only this might be
      > called a "build-down" chart :-) that might also get logged to a team
      > webpage/blog or maillist that reports build failures and all info about
      > them.
      >
      > Or if youre after something more general that just gives codeline status
      > reporting including both of the above kinds of events, plus perhaps a
      > few others. So the version-control or codeline status reports might
      > notify us when:
      > * a new change is committed
      > * the build/codeline breaks
      > * a new label/tag is created or promoted
      > * some kind of daily (or other periodic) report that gives basic metrics
      > about # of commits/integrations, integration/build rates or cycle-times,
      > etc.
      >
      > > it easy to introduce change. A by product of such an environment is
      > > stability in the face of rapid change. So one could tie the these
      > > together as dependency and dependant.
      >
      > You might be interested in one or more of the following:
      >
      > * Continuous Coordination: A New Paradigm for Collaborative Software
      > Engineering Tools; by Andre van der Hoek et.al; available from the
      > "Palantir" project at
      > <<http://www.ics.uci.edu/~asarma/Palantir/publications.shtml>> (PPT at
      > <<http://www.erenkrantz.com/Geeks/Research/presentations/Palantir%20Presentation.ppt>>)
      >
      > * Building Collaboration into IDEs [be sure to check out the RESOURCES
      > section of this one]
      > (<<http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=104&page=1>>)
      >
      > * Breaking The Code: Moving Between Private & Public Work In
      > Collaborative Software Development; by David Redmiles et.al; ICSGW 2003
      > ( <<http://www.ics.uci.edu/~redmiles/publications/>> )
      >
      > * Tactical Approaches for Alleviating Distance in Global Software
      > Development; by Erran Carmel and Ritu Agarwal; IEEE Software,
      > March/April 2001
      > (<<http://www.american.edu/ksb/mogit/carmel/ieeesw2001.pdf>>)
      >
      > * Unifying Artifacts & Activities visually for distributed software
      > development teams; Jon Froehlich et.al.; ICSE 2004;
      > (<<http://drzaius.ics.uci.edu/~jfroehli/augur/pubs/froehlich_j-ICSE2004.pdf>>)
      >
      > * A Weakly Constrained Approach To Software Change Coordination; by
      > Ciaran O'Reilly; ICSE 2004;
      > (<<http://delivery.acm.org/10.1145/1000000/999409/21630066.pdf?key1=999409&key2=5364055011&coll=GUIDE&dl=GUIDE&CFID=35807002&CFTOKEN=65347143
      > >>)
      >
      > --
      > Brad Appleton <brad@...> www.bradapp.net
      > Software CM Patterns (www.scmpatterns.com)
      > Effective Teamwork, Practical Integration
      > "And miles to go before I sleep" --Robert Frost
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >


      --
      Jay Flowers
      ----------------------------------------------------------------------
      http://jayflowers.com
      ---------------------------------------------------------------------
    • Brad Appleton
      ... Yeah - it looks very promising from the abstract (for Continuous Coordination from the publications page at
      Message 2 of 13 , Nov 11, 2005
      • 0 Attachment
        > I have read the paper on Continuous Coordination I thought it was a
        > great idea. I think it ties in with Micheal Feathers statements about
        > Lag Time in "Working Effectively with Legacy Code".
        > <quote>Changes often take a long time for another very common reason:
        > lag time. Lag time is the amount of time that passes between a change
        > that you make and the moment that you get real feedback about the
        > change.</quote>
        >
        > The context for this statement is for an individual but Continuous
        > Coordination is about broadening the scope to the entire dev team.

        Yeah - it looks very promising from the abstract (for "Continuous
        Coordination" from the publications page at
        http://www.ics.uci.edu/~asarma/Palantir/publications.shtml)

        ----- Begin abstract -----

        "Collaborative software engineering tools that have been developed and
        used to date exhibit a fundamental paradox: they are meant to support
        the collaborative ac-tivity of software development, but cause
        individuals and groups to work independently from one another. The
        underlying issue is that existing tools discretize time and tasks in
        concrete but isolated process steps. This approach is fundamentally
        flawed in assuming that human activity can be codified and that periodic
        resynchroniza-tion of tasks is an easy step.

        We propose a new approach to supporting collaborative work called
        continuous coor-dination. The underlying principle is that humans must
        not and cannot have their method of collaboration dic-tated, but should
        be supported flexibly with both the tools and the information to
        coordinate themselves and col-laborate in their activities as they see
        fit. In this paper, we define the concept of continuous collaboration,
        introduce our work to date in building some example tools that support
        the continuous coordination paradigm, and set out a further research
        agenda to be pursued."

        ----- End abstract -----

        Sounds very Agile to me!

        Also check out the paper on maslow's hierarchy of needs for teams, and
        the other one on a collaboration/needs framework for Eclipse.
        --
        Brad Appleton <brad@...> www.bradapp.net
        Software CM Patterns (www.scmpatterns.com)
        Effective Teamwork, Practical Integration
        "And miles to go before I sleep" --Robert Frost
      Your message has been successfully submitted and would be delivered to recipients shortly.