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

Re: [XP] Programming by accident considered harmful

Expand Messages
  • yet another bill smith
    Laurent Bossavit wrote: (snipped, my stuff added at bottom) ... 1. My thanks to J B for putting into clear words some thoughts that had been rattling around
    Message 1 of 7 , May 10, 2002
    • 0 Attachment
      Laurent Bossavit wrote: (snipped, my stuff added at bottom)
      >
      > J.B. :
      >
      > > If I need always to call three methods in a row, you should encapsulate
      > > them into one method for me. That kind of thing. This isn't so much a
      > > testing issue as a design issue, as far as I can see.
      >
      > Oh yup, I agree. No, wait, I don't.
      >
      > > If your code isn't going to fail gracefully when I misuse it, then you
      > > need to take steps to avoid my misusing it.
      >
      > So you say. I don't believe that is true.
      >
      > I make sure that every line of code I write works, by writing rather
      > exacting unit tests before writing the code.
      >
      > If *your* code isn't going to fail gracefully when I misuse it - why,
      > that isn't a problem to me. If it fails, my unit tests will catch
      > that. Then I will take note of the problem and code as I need to, or
      > pair with you to take care of the problem, or whack you upside the
      > head with a rolled-up newspaper if you wrote code that fails
      > gracelessly only because its design sucks.
      >
      > Writing tests before code, we never "program by accident". Why ?
      >
      > In other words, expecting your coworkers to have the test-first habit
      > *is* taking steps to avoid them misusing your code. So you never have
      > to code "defensively".
      >
      1. My thanks to J B for putting into clear words some thoughts that had
      been rattling around between my ears for some time. I love the phrase
      'Programming by Accident' and will shameless borrow the phrase as
      needed, with a cut of my take to J B =-]

      2. (Aside) How would one write a user story calling for all
      'trios-always-called-togethrr' to be presented as a single method? If
      one succeeds in writing the story, how does one write an automated
      acceptance test for it? I would say it's an issue of 'testing the
      design' rather than 'testing the implementation,' but that sounds like a
      big can of worms awaiting an opener.

      3. There are environments in which you really DO haver to code
      defensively, even paranoidly. Case in point: shrinkwrap product that
      will be sold to as many thousands of people as our marketing department
      can bulls..., er, persuade to buy it. It includes an API to let third
      parties interact with the product. What if the customer makes a small
      mistake in an API call, one that under certain rare circumstances causes
      the product to do something nasty/expensive. Say that 99+ percent of
      the time it works perfectly. Option 1: the API is not programmed
      defensively, so the mistake doesn't get noticed until after it's in
      production. Option 2: the API, being paranoid, notices the error on the
      first test run, spits out an informative message, and shuts down the
      application. WOuldn't all of us prefer Option 2 rather than Option 1?

      4. <rant> I've even seen suggerstions on this mailing list to the effect
      that 'bad things don't happen when you use XP -- don't do any error
      checking!' I really wish the universe I live in were like that, but I'm
      afraid I still occasionally run out of disk space, or memory, or my ISP
      drops my connection. The software I'm running can help me recover from
      these problems, or it can make the problem worse. Rhubarb, rhubarb,
      rhubarb, I think you get the point. </rant>

      5. What do you do if you get a user story that asks for bullet- and
      idiot-proofing? It would be legitimate, would it not, for the Customer
      to decide that defensive programming had business value.

      Donning asbestos underoos, I remain
      Bill Smith. the woods are full of us.
    • schroeder@surfree.com
      On Fri, 10 May 2002 04:39:43 -0400 yet another bill smith ... calling for all ... as a single method? If ... one write an automated
      Message 2 of 7 , May 10, 2002
      • 0 Attachment
        On Fri, 10 May 2002 04:39:43 -0400 yet
        another bill smith <bigbill.smith@...>
        wrote:

        > 2. (Aside) How would one write a user story
        calling for all
        > 'trios-always-called-togethrr' to be presented
        as a single method? If
        > one succeeds in writing the story, how does
        one write an automated
        > acceptance test for it? I would say it's an
        issue of 'testing the
        > design' rather than 'testing the
        implementation,' but that sounds like a
        > big can of worms awaiting an opener.

        Would this not happen anyway in a "large
        enough" program, as a consequence of
        removing duplication?

        If I'm calling the same three lines in sequence
        in more than one place (or maybe more than
        two), it might be a sign that a helper method is
        needed.

        -- Ben Schroeder
        schroeder@...
      • schroeder@surfree.com
        ... bigbill.smith@verizon.net ... story calling for all ... presented as a single method? If ... does one write an automated ... issue of testing the ...
        Message 3 of 7 , May 10, 2002
        • 0 Attachment
          On Fri, 10 May 2002 08:38:03 -0400 I wrote:

          > On Fri, 10 May 2002 04:39:43 -0400 yet
          > another bill smith <
          bigbill.smith@...>
          > wrote:

          >> 2. (Aside) How would one write a user
          story
          calling for all
          >> 'trios-always-called-togethrr' to be
          presented
          as a single method? If
          >> one succeeds in writing the story, how
          does
          one write an automated
          >> acceptance test for it? I would say it's an
          issue of 'testing the
          >> design' rather than 'testing the
          implementation,' but that sounds like a
          >> big can of worms awaiting an opener.

          >Would this not happen anyway in a "large
          >enough" program, as a consequence of
          >removing duplication?

          Alternately, are you talking about a situation
          where your product is some kind of API and
          your customer wants this thing to happen with
          externally visible methods, so duplication
          removal wouldn't really kick in?

          If so, maybe they could specify the helper
          method as the one to expose in their API User
          Story. The test could be a Source Test.

          (See "http://c2.com/cgi/wiki?SourceTest".)

          -- Ben Schroeder
          schroeder@...
        • yet another bill smith
          ... The original point was made by J B of Diaspar Software, I was just picking up on Laurent s reply to him. The environment that J B postulated was one in
          Message 4 of 7 , May 10, 2002
          • 0 Attachment
            schroeder@... wrote:
            >
            > On Fri, 10 May 2002 04:39:43 -0400 yet
            > another bill smith <bigbill.smith@...>
            > wrote:
            >
            > > 2. (Aside) How would one write a user story
            > calling for all
            > > 'trios-always-called-togethrr' to be presented
            > as a single method? If
            > > one succeeds in writing the story, how does
            > one write an automated
            > > acceptance test for it? I would say it's an
            > issue of 'testing the
            > > design' rather than 'testing the
            > implementation,' but that sounds like a
            > > big can of worms awaiting an opener.
            >
            > Would this not happen anyway in a "large
            > enough" program, as a consequence of
            > removing duplication?
            >
            > If I'm calling the same three lines in sequence
            > in more than one place (or maybe more than
            > two), it might be a sign that a helper method is
            > needed.
            >
            The original point was made by J B of Diaspar Software, I was just
            picking up on Laurent's reply to him. The environment that J B
            postulated was one in which he (the User) was Not a coworker of the
            programmers. In other words, the people writing the product in question
            had no real feedback about how J B was going to use the product. So the
            duplication occurs in J B's code, which is never seen by the people who
            wrote it that way.

            It seems to me that if _everybody_ _always_ used the three calls
            together, it would be better to have made a one-call interface. If _lots
            of people_ _usually_ use them together, having an option for all-in-one
            would improve the product's usability. If _nobody but J B_ _ever_ uses
            his 3-in-1 way, then having an option for it would be gold-plating.
          • yet another bill smith
            ... Yes, you ve got it, except that this particular User was not involved in writing User Stories. I guess I was thinking that a test for this would be some
            Message 5 of 7 , May 10, 2002
            • 0 Attachment
              schroeder@... wrote:
              >
              > >> 2. (Aside) How would one write a user
              > story
              > calling for all
              > >> 'trios-always-called-togethrr' to be
              > presented
              > as a single method? If
              > >> one succeeds in writing the story, how
              > does
              > one write an automated
              > >> acceptance test for it? I would say it's an
              > issue of 'testing the
              > >> design' rather than 'testing the
              > implementation,' but that sounds like a
              > >> big can of worms awaiting an opener.
              >
              > >Would this not happen anyway in a "large
              > >enough" program, as a consequence of
              > >removing duplication?
              >
              > Alternately, are you talking about a situation
              > where your product is some kind of API and
              > your customer wants this thing to happen with
              > externally visible methods, so duplication
              > removal wouldn't really kick in?
              >
              > If so, maybe they could specify the helper
              > method as the one to expose in their API User
              > Story. The test could be a Source Test.
              >
              Yes, you've got it, except that this particular User was not involved in
              writing User Stories. I guess I was thinking that a test for this would
              be some kind of "usability" or "human-computer-interface" test--tests
              that are normally performed with live warm bodies. The idea of using
              Source Tests as a measure of usability sounds intriguing.
            • Russell Gold
              ... I took J B s plaint to be that the design of the API practically forced him to call the three methods together. You certainly did not have to, but if you
              Message 6 of 7 , May 10, 2002
              • 0 Attachment
                At 10:13 AM 5/10/2002 -0400, yet another bill smith wrote:
                >schroeder@... wrote:
                > > If I'm calling the same three lines in sequence
                > > in more than one place (or maybe more than
                > > two), it might be a sign that a helper method is
                > > needed.
                > >
                >The original point was made by J B of Diaspar Software, I was just
                >picking up on Laurent's reply to him. The environment that J B
                >postulated was one in which he (the User) was Not a coworker of the
                >programmers. In other words, the people writing the product in question
                >had no real feedback about how J B was going to use the product. So the
                >duplication occurs in J B's code, which is never seen by the people who
                >wrote it that way.
                >
                >It seems to me that if _everybody_ _always_ used the three calls
                >together, it would be better to have made a one-call interface. If _lots
                >of people_ _usually_ use them together, having an option for all-in-one
                >would improve the product's usability. If _nobody but J B_ _ever_ uses
                >his 3-in-1 way, then having an option for it would be gold-plating.

                I took J B's plaint to be that the design of the API practically forced him
                to call the three methods together. You certainly did not have to, but if
                you didn't, you ran the risk of a poorly designed program doing something
                catastrophic. It would never be caught by unit tests because they were
                written by people who knew the product thoroughly and never made this kind
                of error.

                As a simple example, imagine that popping an element from an empty stack
                causes a system crash. The developers of this stack class have provided an
                'isEmpty' method, but none of their tests actually try to pop something
                from an empty stack. But a user of the class could very well do so by
                error, so he has to establish a defensive coding standard that insists on
                calling 'isEmpty' before 'pop'. This is, as J B notes, a design problem -
                the 'pop' method should have been designed to assert that the stack was not
                empty and throw an exception if it is.
              • schroeder@surfree.com
                On Fri, 10 May 2002 10:25:25 -0400 yet another bill smith ... User ... User was not involved in ... computer-interface test--tests
                Message 7 of 7 , May 10, 2002
                • 0 Attachment
                  On Fri, 10 May 2002 10:25:25 -0400 yet
                  another bill smith <bigbill.smith@...>
                  wrote:

                  >> If so, maybe they could specify the helper
                  >> method as the one to expose in their API
                  User
                  >> Story. The test could be a Source Test.
                  >>
                  > Yes, you've got it, except that this particular
                  User was not involved in
                  > writing User Stories. I guess I was thinking
                  > that a test for this would
                  > be some kind of "usability" or "human-
                  computer-interface" test--tests
                  > that are normally performed with live warm
                  bodies. The idea of using
                  > Source Tests as a measure of usability
                  sounds intriguing.

                  I was just thinking that it would be a way for
                  the API User to see that her Story turned out
                  OK, but that is an interesting idea.

                  I suppose that the developers of the API would
                  have had (if they were programming that way)
                  test cases for their API... maybe a Source Test
                  could look for duplication in calling
                  sequences there as a measure of how
                  "usable" the API was.

                  (The programmers of the tests might, of
                  course, be able to do just as good a job or
                  better without the automation. I am woefully
                  ignorant of whether tools would do a good job
                  flagging such duplication.)

                  -- Ben Schroeder
                  schroeder@...
                Your message has been successfully submitted and would be delivered to recipients shortly.