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

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

Expand Messages
  • Torbjörn Gyllebring
    Hi George, On Tue, Dec 30, 2008 at 3:33 PM, George Dinwiddie ... I think there s an XP way of handling this, The simplest thing that could possibly work :)
    Message 1 of 61 , Dec 30, 2008
      Hi George,

      On Tue, Dec 30, 2008 at 3:33 PM, George Dinwiddie
      <lists@...> wrote:
      > 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.

      I think there's an XP way of handling this, "The simplest thing that
      could possibly work" :)

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

      Yes, I think that we all agree that the ultimate goal in this case is
      towards TDD and increased agility, any metrics or auxillary process
      introduced should be evaluated against if it does help us come closer
      to feel confindent in being able/allowed to continue with that
    • 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

        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.