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

Re: [XP] Re: Scrum, and Revolution

Expand Messages
  • Tom Rossen
    Rob said * ... better comes along, for me it s TDD or the highway....* * * 35 years in my case, and amen! Here s a snippet from the cover letter I ve been
    Message 1 of 167 , Dec 27, 2012
    • 0 Attachment
      Rob said
      *

      >> But I've been programming for over 30 years, and until something truly
      better comes along, for me it's TDD or the highway....*
      *
      *
      35 years in my case, and amen! Here's a snippet from the cover letter I've
      been sending out recently:

      *I am looking for a situation (preferably permanent, but contracting on W2
      or corp2corp if necessary) in a software development environment that
      either uses real Agile practices (as opposed to a few fake buzzwords) or is
      interested in moving toward Agile. I will be happy to coach/mentor other
      developers on Agile techniques.*

      *Specifically, I consider a bias against TDD (Test-Driven Development) a
      showstopper: I will not work for an organization that does not allow me to
      develop code that way. (If the company doesn't even recognize the initials,
      that's a bad sign in itself.)*

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

      *...*

      When I started my current contract at an investment bank with an IT
      department that still forces all developers to use Windows XP, I could have
      sworn that pair programming would be the toughest sell. But that was a
      piece of cake compared to TDD. Programmers in waterfall/cowboy
      environments are forced to develop their own private esthetics and rhythms
      to survive, because underlying the cmd&ctl fantasy of structure is a chasm
      of chaos, and TDD is a wrenching change for them. I agree with Rob that it
      tops the list for teams that are new to Agile concepts.


      On Thu, Dec 27, 2012 at 6:19 PM, Rob Myers <rob.myers@...>wrote:

      > **
      >
      >
      > Kay,
      >
      >
      > --- In extremeprogramming@yahoogroups.com, "Kay A Pentecost" <tranzpupy@...>
      > wrote:
      > > > Most of my first-person XP success stories involve avoiding horrors, so
      > > > I'm not sure if they meet your criteria.
      > >
      > > I was thinking of problems that existed before implementing agile
      > practices,
      > > that the agile practices solved... but success stories are great, too.
      >
      > Ah, okay. Let's see, I started programming for a living around 1984...
      >
      > In 1997 I was looking for a way out of the software industry. I was
      > disillusioned in so many ways. Then in 1998, our team was abruptly
      > introduced to Extreme Programming, and I haven't been the same since! :-)
      > So, problems that Agile has solved for me:
      >
      > 1. Top of my list is TDD, a technique that encourages us to write the
      > other half of the problem/solution equation, thus making sure our solution
      > solves the right problems, and continues to do so in perpetuity. What it
      > did for me is provide safe refactoring, so I could update functionality
      > without having to ruin my design with ugly retrofitted code. The old way,
      > trying to carefully retrofit by creating entirely separate code-paths, was
      > either challenging to maintain later, or was error-prone. Or both.
      >
      > 2. Given #1 above, we could allow Product folk to alter the trajectory of
      > the product and respond to market forces. This was invigorating for
      > everyone, and allowed for stratospheric levels of innovation. Since we
      > could build and demonstrate working software incrementally, we avoided what
      > I had seen in the past: We'd get the whole thing completed, and have the
      > client cancel on us.
      >
      > I even had one client pay the whole invoice after telling my team that
      > they could no longer use what we had spent a year building for them (an
      > elaborate, mainframe-driven coast-to-coast HyperChannel remote printing
      > protocol). We were at the client site installing the software when they
      > told us. Was that a success? Even though we were paid in full, I call it a
      > failure. Great development teams want to know their software is being used
      > to provide value.
      >
      > With Agile, we can know within two weeks, not 12 months, whether or not
      > we're on the right track.
      >
      > 3. Working in collaborative teams, rather than separate offices, allowed
      > many of us to discover that we knew more than we thought, and that it was
      > okay to not know something, because you could learn on-the-job from your
      > peers. E.g., I had taken early "OO" courses, which taught the
      > "subclass-to-improve" aka "subclass for specialization" school of OO
      > design, which was a big load of horseplop. By pair-programming, we quickly
      > noted that good OO was mostly common sense, and--behold!--GoF Design
      > Patterns emerged from merciless refactoring and were identified with the
      > help of our wise XP coach, Fred George.
      >
      > Contrast that with sending me to a security and encryption conference in
      > the mid-90's, where I learned about Kerberos and RSA public-key encryption.
      > I returned excited with my new-found knowledge, of course. The only use I
      > got out of it was a lingering awareness of the foolishness of
      > password-based security and algorithmic "randomness."
      >
      > 4. Doing things the "Agile" way showed us very early on how crappy some of
      > our dev tools were. In 2001 we started with JBuilder, which was--at that
      > time--a challenge. We discovered IDEA, which seemed to be uniquely tuned to
      > Agile development. In many other areas, Agile teams have encouraged, or
      > built, replacement tools that are not themselves bottlenecks to real
      > productivity: Resharper, Rails, Cucumber, SpecFlow, Git, et cetera.
      >
      > > > http://www.quora.com/Does-test-driven-development-TDD-really-improve-
      > > > software-quality/answer/Rob-Myers
      > >
      > > Unfortunately, this site wants me to sign in with Facebook or Twitter,
      > and
      > > I'm limiting my connections to Facebook & Twitter. I'd love it if you
      > could
      > > send me a copy....
      >
      > Here's the text from my Quora answer. (Who knows when the blog post will
      > get done... ;-)
      >
      > <quote>
      > TDD provides lower defect rates, higher productivity, and a much more
      > logical and fun technique for us scientifically-minded problem solvers.
      >
      > I've worked on at least 5 projects as a TDD developer and XP coach (before
      > moving to more general Agile coaching and training, including TDD
      > training). The reduction in the amount of bugs we saw vs. non-TDD projects
      > was astounding. In the 2001 project, we saw perhaps one defect per month
      > reported from the field, and we had customers in the US, Canada, Japan.
      > Most were found and fixed (forever) in one iteration.
      >
      > The 2002 project was a life-critical (i.e., "You make a mistake, someone
      > may die") rewrite, and I don't recall a single business-logic bug (I recall
      > one PDF formatting complaint) in over a year. We found more bugs in the old
      > legacy product (the one being rewritten) by using its reporting results as
      > input to our acceptance-test cases, and manually comparing failures.
      >
      > And on and on.
      >
      > Those who say it's slower are looking only at the early results, and early
      > challenges. If I were building a tiny app that I never expected to have to
      > support, I might not get the ROI from TDD. But then, I don't think the VCs
      > would expect any ROI either.
      >
      > After months of comprehensive microtesting and merciless refactoring,
      > teams often find a story in their queue that would have otherwise taken
      > them months to build, but it takes mere days.
      >
      > In my own, first-person experience:
      >
      > * Convert a suite of web apps to internationalized input and output after
      > over a year committed to only one character-set? Three days.
      >
      > * Add a functioning "Display in PDF" button to every one of a hundred HTML
      > reports after having committed 6 months to HTML-only? Three days.
      >
      > * Re-purpose a hand-crafted FoxPro-to-Oracle schema-and-data conversion
      > tool to convert another department's database on-demand and feed those
      > results into that department's separate report-generator at a savings of
      > hundreds of thousands of dollars per year? Two days.
      >
      > A lack of comprehensive, automated, fast regression tests is one of the
      > top three or four reasons why Agile projects fail. Of course, TDD is not a
      > silver bullet, but it solves so many challenging problems. It's one of the
      > first Agile engineering practices I would put into place on any Agile team.
      > (To do otherwise would be unprofessional, irresponsible, and, in some
      > cases, dangerous.) If someone finds a better way, I'll try it. But I've been
      > programming for over 30 years, and until something truly better comes
      > along,
      > for me it's TDD or the highway: I'm not one who can stay and watch
      > people suffer needlessly.
      > </quote>
      >
      > Take care,
      >
      > Rob
      >
      > Rob.Myers@...
      > Twitter: @agilecoach
      > http://www.agileInstitute.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
      • 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.