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

Re: [XP] Re: Testing increasing time significantly?

Expand Messages
  • George Dinwiddie
    ... This must be done very deftly, or the organization is likely to get stuck in the tarpits of a major metrics program, spending their time trying to perfect
    Message 1 of 61 , Dec 30, 2008
      Torbjörn Gyllebring wrote:
      > Hi Charlie,
      >
      > On Tue, Dec 30, 2008 at 3:36 AM, Charlie Poole
      > <charlie@...> wrote:
      >> It's true that *if I am successful* the total cost over
      >> time will be reduced and/or the software improved. But
      >> I haven't yet found a way to get people to assume I'll
      >> be successful. Most managers want to assess risks and
      >> one risk is that we might invest some time and money
      >> and never see the promised outcome.
      >
      > Isn't this the long standing issue of most organizations (or actually
      > all that I've experienced) don't actually have the maturity to and
      > means to know if they're improving. Im more and more starting to think
      > that the first step to successfully introducing agile or any element
      > thereof is to first convince "management" that they need to get a grip
      > on their present reality. What are their defect rate? how long is
      > their cycle time? How often do they fail to deploy into a live
      > environment? How much time is spent fire-fighting?
      > Unless you already care deeply about the current state of affairs how
      > can you really know that it's improving?

      This must be done very deftly, or the organization is likely to get
      stuck in the tarpits of a major metrics program, spending their time
      trying to perfect which metrics to record rather than actually making
      improvements.

      In the situation Charlie describes, the organization already knows
      /something/ about the state of their present process, or they wouldn't
      be talking with him. I would rather make use of the things they've
      /already observed/, if possible. If they're going to make a reluctant
      change, I'd rather it be in the direction of TDD than in the direction
      of more metrics.

      The questions you ask are very good ones to bring up with them, to
      increase the breadth of their awareness about their current process.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • J. B. Rainsberger
      ... I m late to the party, so this might be old news by now. Don t compare apples to oranges. When you consider the cost of delivering that story without doing
      Message 61 of 61 , Jan 15, 2009
        On 2008-12-24, at 19:29 , Brandon Olivares wrote:
        > So I decided to put an honest effort into trying TDD.
        >
        > My feeling about it after trying it on a single user story is that
        > it's
        > really, really useful, and gives a lot of assurance, but is a pain
        > to write,
        > and increases the time to program significantly. I estimate it
        > increased the
        > time it took me to program this threefold, from what it would have
        > been had
        > I not used tests. I had 54 unit tests and 92 functional tests, so it
        > definitely was a lot to write.
        >
        I'm late to the party, so this might be old news by now.

        Don't compare apples to oranges. When you consider the cost of
        delivering that story without doing TDD, including the cost to program
        it, the cost to fix all the defects you and your testing organization
        find, the cost to plan and decide which defects to fix and which
        defects to risk delivering to your customer, the cost to argue with
        your testers about whether something is a defect or not, and the cost
        to go back and rewrite 40% of that code in three months when you try
        to add a feature that touches your design and you learn that your old
        design is too rigid to accommodate the new feature.

        If you add up all those costs, you might find a vastly different
        comparison.

        Also, as with any technique, with practice comes speed.
        ----
        J. B. (Joe) Rainsberger :: http://www.jbrains.ca
        Your guide to software craftsmanship
        JUnit Recipes: Practical Methods for Programmer Testing
        2005 Gordon Pask Award for contributions to Agile Software Practice
      Your message has been successfully submitted and would be delivered to recipients shortly.