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

Re: [XP] Re: Scrum, and Revolution

Expand Messages
  • Adam Dymitruk
    I hear you. A good chunk of this work is fixing data. So no coding even. On Mon, Dec 24, 2012 at 12:46 PM, Leonardo Postacchini ... -- -- Adam www.dymitruk.com
    Message 1 of 167 , Dec 24, 2012
      I hear you. A good chunk of this work is fixing data. So no coding even.

      On Mon, Dec 24, 2012 at 12:46 PM, Leonardo Postacchini
      <notivago@...>wrote:

      > **
      >
      >
      > 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]
      >
      >
      >



      --
      --

      Adam

      www.dymitruk.com


      [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
        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.