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

Re: [XP] Re: Scrum, and Revolution

Expand Messages
  • Leonardo Postacchini
    What do you mean by learning? Because there is much to learn from legacy systems with easy, boring and time consuming . For example, if this is easy and
    Message 1 of 167 , Dec 24, 2012
    • 0 Attachment
      What do you mean by learning? Because there is much to learn from legacy
      systems with "easy, boring and time consuming".

      For example, if this is easy and boring and time consuming, for me there is
      a Smell there. Legacy maintenance should not be time consuming, unless you
      have tons of bugs and duplication of code, if so, refactoring is in order
      and thus a lot to learn, learning here also encompass "learn new ways of
      doing stuff".

      Also by pairing and rotating people among teams: legacy and new, to say
      some of the advantages, you :
      - Diminish frustration, for no one feels punished by being stuck on the
      legacy code.
      - People will feel confident to make changes in the legacy that simplifies
      it and reduces work.
      - Keep the flow of know-how from the legacy to the new code.

      Your statement seem to me more lack of belief on pair or understanding of
      all its benefits than "vision" of when to use it or not.

      Sometimes working on legacy code, easy, time consuming, and boring, is
      well: boring and bored people wander away, start to read mail, browse the
      web, play mobile apps, go take long snack, so on and so forth.

      Pairing alone keep people refreshed by social iteration an makes they stay
      on top of the job.


      On 24 December 2012 18:20, Adam Dymitruk <adam@...> wrote:

      > **
      >
      >
      > Working with a team that was transitioning to Agile, I noticed that pairing
      > did not make sense for a department that was left in the maintenance of
      > legacy code while the others were working on systems to replace the old
      > system. This maintenance team was stuck with dead easy boring and time
      > consuming tasks where pairing would not have helped. There was very little
      > learning to be done there. For new members pairing was done on a as needed
      > basis. Like anything, you can't apply it blindly.
      >
      > Adam
      >
      >
      > On Fri, Dec 21, 2012 at 11:25 AM, Adam Sroka <adam.sroka@...> wrote:
      >
      > > Using scientific research to decide how to conduct your life/work is like
      > > driving with sonar. Your likely to go the wrong way and maybe run into
      > some
      > > shit. A better strategy would be to try it out and be mindful while you
      > are
      > > doing it.
      > >
      > >
      > > On Fri, Dec 21, 2012 at 3:56 AM, Steven Gordon <sgordonphd@...>
      > > wrote:
      > >
      > > > **
      > > >
      > > >
      > > > Research in software development is extremely problematic for a number
      > of
      > > > reasons related to it being research in the behavior of many
      > interacting
      > > > humans as opposed to a well-defined, deterministic system. It is not
      > just
      > > > about the code.
      > > >
      > > > It would be extremely expensive to do anything approaching double-blind
      > > > experiments on professional programming teams doing the same
      > non-trivial
      > > > projects in contexts that are identical except for the variable being
      > > > evaluated. Furthermore, if they were real Agile projects, we should
      > > expect
      > > > the contexts to diverge over time no matter what controls we put in.
      > > >
      > > > Anything short of a well designed, fully controlled experiment is not
      > > > definitive. Any number of other variables could be responsible for the
      > > > observed results, including well known side-effects of subjects knowing
      > > > they are part of an experiment (and/or the context is too
      > > > trivial/short-lived to be applicable to what actually happens in the
      > > wild).
      > > >
      > > > Therefore, we have nothing better than studies like these.
      > > >
      > > > It is a bit more feasible to do controlled experiments
      > > > on command-and-control/waterfall projects (but still not easy or
      > > > inexpensive). There was a time when the US Defense Department funded a
      > > few
      > > > such studies. At that time, there were studies that pretty well
      > establish
      > > > the efficacy of formal code reviews done correctly (in the context of
      > > > non-trivial, non-agile projects). Some would say that if we do not do
      > > pair
      > > > programming, then we should do formal code reviews.
      > > >
      > > > I would make the analogy:
      > > > formal code reviews : pair programming ::
      > > > manual testing : TDD/ATDD.
      > > >
      > > > In other words, formal code reviews should be less effective than pair
      > > > programming because it happens after the fact and therefore creates a
      > > > feedback loop with a much longer latency time. Of course, I cannot
      > prove
      > > > it.
      > > >
      > > > Steven Gordon, PhD
      > > >
      > > > On Fri, Dec 21, 2012 at 4:17 AM, M. Manca <
      > m.manca@...
      > > > >wrote:
      > > >
      > > > > **
      > > > >
      > > > >
      > > >
      > > > > Il 21/12/2012 10:45, Steven Gordon ha scritto:
      > > > >
      > > > > >
      > > > > >
      > > > > > On Fri, Dec 21, 2012 at 2:01 AM, Andy Glew (Gmail)
      > > > > > <xp-list@... <mailto:xp-list%40patten-glew.net>>wrote:
      > > > >
      > > > > >
      > > > > > > The usual question about references.
      > > > > > >
      > > > > >
      > > > > > The usual answer about references:
      > > > > >
      > > > > > http://scholar.google.com/scholar?q=pair+programming+research
      > > > > >
      > > > > When I search papers and studies to know in advance what results I
      > > > > should obtain, I rarely find studies made with equity and objectivity
      > > if
      > > > > the object is a development method. Of course I read some of them,
      > > those
      > > > > don't related to "programming introductory courses" and "students
      > > > > application", and after having found a lot of papers presenting
      > numbers
      > > > > without any sense in both directions (it works better or not) I
      > stopped
      > > > > to search and read.
      > > > >
      > > > > For instance I read "Experimental Evaluation of Pair Programming1 "
      > by
      > > > > Jerzy Nawrocki, AdamWojciechowski that compares PSP (PSP0) with XP
      > made
      > > > > by 1 student and XP made by paired students.
      > > > >
      > > > > Having used all of these methods of course I had my (different)
      > results
      > > > > so I am convinced that:
      > > > >
      > > > > 1. PSP is better described then applicable and it requires too data
      > to
      > > > > collect
      > > > > 1. the applications where too little to perform a serious analysis
      > > > > 2. if you didn't use PSPt before the compare trial you will loose
      > more
      > > > > time then the XP teams
      > > > > 3. problems were too simple to require a design phase as requested by
      > > PSP
      > > > > 4. the problem with PSP0 is that the development is not iterative,
      > > > > iterations are inserted by PSP3
      > > > > 5. the XP process was simplified more then PSP0
      > > > >
      > > > > Best of all, considering that XP2 were pair programming teams, I
      > don't
      > > > > see a consistent improvement cutting development time or increasing
      > > > > quality of the applications (they were too simple probably) compared
      > to
      > > > > other teams, so I think the experiment had no meaning because all the
      > > > > participants were more or less newbies. Also in the conclusion point
      > > the
      > > > > authors admit that the results were too different then expected.
      > > > >
      > > > > About Pair Programming:
      > > > > 1. I haven't the feel it can cut development time by 50%, because the
      > > > > reduction seems to be more related to other factors.
      > > > > 2. In a project where requirements don't change quickly and the
      > > > > algorithms are complex I am sure that Pair Programming pays more then
      > > > > other strategies but not so much, it may reduce development time by
      > > > > 20-25%. In other situations where the engineers have a good
      > experience
      > > > > and knowledge it increase the development time by 50-60%.
      > > > > 3. I have the feel that to solve complex problems is the best viable
      > > > > solution, I think at it as a "sw swat team tactic"
      > > > > 4. I have the feel that after some general introduction is the better
      > > > > way to introduce new engineers in a XP project team
      > > > >
      > > > > So in my opinion, if a pair of normal engineers may work with the
      > same
      > > > > results of a skilled engineer should be a general viable solution
      > > > > because it is quite impossible in the most organization I know that 2
      > > > > skilled engineers should be paired for a long time if their
      > development
      > > > > time will not cut over 50%.
      > > > >
      > > > >
      > > >
      > > > [Non-text portions of this message have been removed]
      > > >
      > > >
      > > >
      > >
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.comYahoo! Groups Links
      > >
      > >
      > >
      > >
      >
      > --
      > --
      >
      > Adam
      >
      > www.dymitruk.com
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Tom Rossen
      Rob, Thanks for your kind offer. I am currently gainfully employed - until Feb. 2, when my current contract runs out. Northern Trust renewed it as many times
      Message 167 of 167 , Dec 30, 2012
      • 0 Attachment
        Rob,

        Thanks for your kind offer. I am currently gainfully employed - until Feb.
        2, when my current contract runs out. Northern Trust renewed it as many
        times as they could, but there's a hard limit of 1.5 years.

        Re the high-performing teams: it's funny, but I really think I prefer
        working with an organization that's struggling with Agile. I'm extremely
        curious as to why XP practices, which seemed so obvious and satisfying when
        I first read Kent Beck's book years ago, are so frustrating for developers
        and managers who aren't used to them and didn't volunteer for them. I was
        rather seriously burned on my previous engagement when the company was
        acquired by a conglomerate and the policy of openness to Agile suddenly
        evaporated, so my insistence on TDD - which no longer seems as doomed as it
        would have been just a year ago, based on what I'm seeing now in the
        Chicago area - is protection against that sort of thing.

        So I'm curious about the high-performing teams you mention - at least in
        the Chicago area: I don't intend to relocate or commute a long distance (I
        worked in Madison, WI for several years after the dot-com-bomb wiped out
        the Chicago market - not a fun commute).

        Tom


        On Fri, Dec 28, 2012 at 2:30 PM, Rob Myers <rob.myers@...>wrote:

        > **
        >
        >
        > Tom,
        >
        > Thanks for the supportive reply!
        >
        >
        > > 35 years in my case, and amen! Here's a snippet from the cover letter
        > I've
        > > been sending out recently:
        >
        > Tom, if you are not currently gainfully employed, I can point you to a few
        > truly high-performing teams across the country. They are in the minority,
        > as most software/IT organizations struggle to change those
        > command-and-control cultures, and to foster passion and creativity in both
        > Product and Development areas.
        >
        > > *I just thought of an analogy to explain why I am so single-minded about
        >
        > > TDD. Suppose you need an operation and you're looking for a hospital to
        > do
        > > it. A major hospital sends you a wonderful brochure explaining how
        > > successful they are, what a high-tech surgical suite they have,, etc.,
        > etc.
        > > But when you call up and ask them whether the surgeons wash their hands
        > > before operating, they say, "Why would we want to do that?" Oh yes,
        > > surgery was practiced for centuries before surgeons ever scrubbed up -
        > it's
        > > a great tradition. But I don't think you'd want to have anything to do
        > with
        > > a hospital like that. That's how I feel about TDD. It's a matter of
        > > funda**mental
        > > software hygiene. *
        >
        > It's a perfect analogy. Scott Bain uses this in his book /Emergent Design/
        > as one example of how software development is similar to surgery. (Aside:
        > Apologies if I popped an original-idea bubble: So often I find I think of
        > something original, only to spot it in a blog post the next day. It's the
        > Newton-Leibniz Effect ;-) The medical field provides an analogy that gets
        > us much farther than bridge-building. Of course, no analogy is perfect, but
        > I often find myself thinking "Doctor, it hurts when I do *this*!" ;-)
        >
        > Happy Holidays!
        >
        >
        > Rob
        >
        > Rob.Myers@...
        > Twitter: @agilecoach
        > http://www.agileInstitute.com/
        >
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.