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

Re: [XP] New Agile Vehicles

Expand Messages
  • Laurent Bossavit
    Hi Josh, ... I m not sure who you have in mind, but... if the people *touching* the code don t have a handle on technical debt, nobody does. What programmers
    Message 1 of 216 , Nov 10, 2010
      Hi Josh,
      > I'm glad you said how *people* approach code, because it's a much
      > larger
      > issue than just what programmers do.
      >

      I'm not sure who you have in mind, but... if the people *touching* the
      code don't have a handle on technical debt, nobody does. "What
      programmers do" is too big a deal to warrant that little word "just".

      Now, assuming programmers who *do* have their wits about them, you
      still need to communicate to other constituencies about what the
      programmers are seeing directly, and help them act effectively on that
      information. That includes people in testing (or QA if it's called
      that), product owners who are dealing with the business side of those
      risks, and so on.

      But you can't short-circuit the programmers. That doesn't keep people
      from trying - there's this old fantasy of "tools that measure
      technical debt just by parsing the source code". This is the too
      common fallacy of reification, of assuming that because you have a
      concept of "technical debt" it's something objective, "out there",
      that you can measure the way you'd measure oxidation of metals. That
      doesn't work, because what we're dealing with is relational - it's
      about how well a specific bunch of programmers with specific tools and
      habits are able to deal with a specific code base.

      A really, really bright idea from one of my friends, Regis Medina, was
      to apply the techniques of usability testing to source code, and more
      broadly to consider source code "the programmer's UI onto the
      project". Unfortunately he's been too busy recently to develop it much
      further but I think it has legs. (As has the related transpositon of
      "process as the manager's UI onto the project".)

      Another thing I think is cool is Coding Dojos, not so much for what
      they are but for the directions they point in. For instance, some
      research into pair programming suggests that it's not so much the
      pairing that is effective, but rather the act of "programming out
      loud". Dojos tap into that as a way of teaching programmer skills.

      > We may only get one huge step forward, like TDD, every decade.

      That shoudn't keep us from trying. How long does it take to have an
      innovative idea? If you have enough of them, sooner or later you'll
      hit on a game-changer. I've been fooling around with a technique known
      as the "zwicky box", but there are others that might work,
      brainstorming and so on. Back in the early oughts, as I remember it,
      there was a lot of such kicking ideas around going on, and things seem
      to be a little more tame of late, possibly because of entrenchments of
      the Agile "vehicles" as you call them, and the money involved, and so
      on. I'd like to see that creativity come back.

      Cheers,
      Laurent Bossavit
      laurent@...
    • Steven Gordon
      On Mon, Jan 24, 2011 at 4:11 AM, D.André Dhondt ... Alternative interpretation: Domains that consider themselves scientific tend to require formal proof
      Message 216 of 216 , Jan 24, 2011
        On Mon, Jan 24, 2011 at 4:11 AM, D.André Dhondt
        <d.andre.dhondt@...> wrote:
        > On Mon, Jan 24, 2011 at 2:08 AM, Amir Kolsky <kolsky@...> wrote:
        >
        >>   And again, one is reminded of Ignaz Philipp Semmelweis…
        >>
        >
        > Meaning that people tend to reject new ideas just because they're new?
        > (Semmelweis suggested surgeons should wash hands with chlorine between
        > patients).

        Alternative interpretation:

        Domains that consider themselves scientific tend to require formal
        proof instead of empirical success before accepting new ideas.

        >
        > --
        > D. André Dhondt
        > mobile: 215-805-0819
        > skype: d.andre.dhondt
        > twitter: adhondt   http://dhondtsayitsagile.blogspot.com/
        >
        > Support low-cost conferences -- http://AgileTour.org/
        > If you're in the area, join Agile Philly http://www.AgilePhilly.com
        >
        >
        > [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
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.