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

RE: [XP] how much to unit test function that calls well-tested functions?

Expand Messages
  • kentb
    Coding with automated tests is gambling too. If you could have had business success without the tests, you would likely have gotten results sooner by
    Message 1 of 60 , Sep 3, 2008
    View Source
    • 0 Attachment
      Coding with automated tests is gambling too. If you could have had business
      success without the tests, you would likely have gotten results sooner by
      eliminating testing (and accelerating delivery may have been critical to
      your success). Coding with tests is more sustainable, but sustainability may
      not be a critical business success factor. OTOH, gambling on not writing
      tests means you're less able to change direction. Each strategy will beat
      the other sometimes. As my pappy used to say, "You pays your money and you
      takes your chances."

      Regards,

      Kent Beck
      Three Rivers Institute


      _____

      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of John A. De Goes
      Sent: Tuesday, September 02, 2008 2:32 PM
      To: extremeprogramming@yahoogroups.com
      Subject: Re: [XP] how much to unit test function that calls well-tested
      functions?




      I really think coding without automated tests is like gambling.
      Sometimes you come out ahead, but most times you go broke. The exact
      percentage depends not just on luck (as for gambling), but on
      programmer skill, language choice, tool set, and so forth.

      I think that's what makes it addictive for many developers. Sometimes
      you write 1000 lines of code and it works perfectly the first go,
      without TDD and without debugging. In these cases, you clearly come
      out ahead by not writing tests, assuming the code will never be
      changed by anyone ever again (an assumption that is wrong in most
      cases -- but how wrong depends on the lifespan of the application).

      TDD and automated testing represent the strategy of minimizing
      variance: the pace is slow and steady and surprises are few and far
      between. They also represent the strategy of minimizing technical
      debt, which easily pays for itself and then some, but only over a
      sufficiently long time frame.

      Some years ago in the gaming industry, it was well-known that most
      titles lost money, and those costs were born by the occasional
      blockbuster (I believe this is still true in the movie industry). A
      very lucky win can cover your losses. Sometimes I wonder if many
      software development companies survive on the same principle. Produce
      crap at full steam ahead. Most of the times the project will end
      badly, but occasionally you'll get lucky and save a bundle. Enough to
      make up for the losses? Perhaps, since many chop shops don't have to
      maintain the crap they produce.

      Regards,

      John A. De Goes
      N-BRAIN, Inc.
      http://www.n- <http://www.n-brain.net> brain.net
      [n minds are better than n-1]

      On Sep 1, 2008, at 6:19 AM, Ron Jeffries wrote:

      > Hello, John. On Monday, September 1, 2008, at 1:14:24 AM, you
      > wrote:
      >
      > > Say you're finishing up a contract job, and know that you won't be
      > > responsible for maintaining the software in the future. Do you come
      > > out ahead or behind by incurring technical debt?
      >
      > I don't think so. Not if it has to work. If it doesn't have to work,
      > as Chet puts it, we are done now.
      >
      > > Or suppose you're part of a start-up, and the VC firm is demanding a
      > > feature-complete release in six weeks, or will cut off funding. Is
      > it
      > > OK to borrow from the future a little to keep your job?
      >
      > I don't think so. I don't think features come out faster when we
      > write crappy code. I think we just feel like it must be better
      > because we're hurrying.
      >
      > What I /would/ do would be cut out the frills. But if the code has
      > to work, writing it ugly doesn't make that more likely.
      >
      > > I think in some cases, you come out ahead by incurring technical
      > debt,
      > > just like in real-life you sometimes come out ahead by borrowing.
      > It's
      > > a gamble, of course, but sometimes the risk-takers actually do beat
      > > the risk-minimizers.
      >
      > Over a day, maybe. Over a week, I think it's not the way to bet.
      > There is one possible exception that I can think of, some kind of
      > rape and paste approach to a million web pages.
      >
      > But even then, since the bastards are going to ask for a change,
      > extracting the code into functions is probably still going to win.
      >
      > I don't know how to do an experiment that we could believe. But I've
      > been coding in various ways and paying attention for a long time
      > now, and I have never failed to get in trouble when I wrote crap.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Ron gave me a good suggestion once. -- Carlton (banshee858)
      >






      [Non-text portions of this message have been removed]
    • John A. De Goes
      Yes, but in the case of a competition, there is no change. It s truly a write-once, throwaway scenario, for which there is no investment to protect. Regards,
      Message 60 of 60 , Sep 13, 2008
      View Source
      • 0 Attachment
        Yes, but in the case of a competition, there is no change. It's truly
        a write-once, throwaway scenario, for which there is no investment to
        protect.

        Regards,

        John A. De Goes
        N-BRAIN, Inc.
        http://www.n-brain.net
        [n minds are better than n-1]

        On Sep 13, 2008, at 9:59 AM, Marty Nelson wrote:

        > > > Let's hold a contest, where the winner is the first one to
        > complete
        > > > the assignment. The assignment is to write a program that prints
        > > > "Hello World". You code a solution with TDD, and I'll code the
        > > > solution with "print "Hello World";"
        > >
        > > > Which one of us will win the competition?
        >
        > To show how horrible wrong even a hello world app can go(and assume
        > this is .NET, not sure how other languages handle this), imagine that
        > for v2 of the app, our customers are raving for it to
        > say "Hello\Goodbye World".
        >
        > So TDD is not just about the solution, but protecting that investment
        > against change...
        >
        >
        >



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.