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

Re: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.

Expand Messages
  • Mike Beedle
    Andy, Great quote but they might in fact be using Haskell. Unit tests are still needed to ensure that programs or components are doing the right thing from
    Message 1 of 37 , Jun 4, 2003

      Great quote but they might in fact be using Haskell.

      Unit tests are still needed to ensure that programs
      or components are doing the "right thing" from the
      functional perspective, but at least the bugs that
      are system related and/or language/paradigm related
      going to be taken care of: memory leaks,
      improper assignments, inconsistent branching,
      infinite looping, improper pre-conditions/post-
      condition, unused coverage, concurrency problems,
      side effect problems, handling of system
      exceptions, etc.

      I don't know if there is a metric for figuring
      out what percentage of bugs comes from system-related
      or language/paradigm related sources - to begin
      with, the ratios are probably language, domain, and/or

      level of complexity dependent; but from experience
      with imperative languages, just cutting on
      system-related problems would definitely be
      a good start,

      - Mike

      --- Andy Cirillo <andycirillo@...> wrote:

      "Beware of bugs in the above code; I have only proved
      it correct,
      not tried it." -- Donald Knuth (in a memo to Peter van
      Emde Boas)

      I just happened to have seen the above quote in
      someone's sig
      recently... I guess he wasn't using Haskell.

      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn"
      > Hmm, when you write HaskellUnit for us, I'll give it
      a try! :)
      > I had brief exposure to Miranda and ML in the early
      90s and my
      brain doesn't
      > think that way. I had a really hard time of it.
      > -Mike
      > -----Original Message-----
      > From: Mike Beedle [mailto:beedlem@e...]
      > Sent: Wednesday, June 04, 2003 2:11 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: RE: [scrumdevelopment] Re: IEEE SWEBOK Is
      Looking for
      > Reviewers--They Don't Even Mention XP, Agile, etc.
      > Micheal wrote:
      > > When the first programming course in a CS
      > > curriculum uses Test Driven Development,
      > > we'll be teaching programming as we should.
      > David M. wrote:
      > >Bottom line... I agree, there was an economic
      > >component to early
      > >"test-first" because of mainframe costs.
      > Mike C. wrote:
      > > Yes, we did "test first" because our training
      > > environment was simulating a high-cost
      > Mike C. wrote:
      > > I went for a 3-week COBOL training class outside
      > > Chicago and we were very definitely taught to
      > > tests first.
      > David A. wrote:
      > > On a more serious note - the "test first" concept
      > > was driven out of economics - the high cost of
      > > computer time.
      > Test-first makes more sense specially for
      > imperative modes of programming i.e. Java, C,
      > Smalltalk, C++, Objective C, COBOL, etc.; where
      > we use unit tests to ensure quality of system
      > issues: memory, assignment, branching, looping,
      > conditions, coverage, side effects, and
      > handling of system exceptions.
      > What the world needs to accept is that
      > declarative programming paradigms lead to a much
      > higher
      > quality to begin with because they avoid
      > system errors and in many cases guarantee
      > Haskell, Clips, Prolog, Erlang, etc., etc.
      > http://www.haskell.org/aboutHaskell.html
      > http://www.md.chalmers.se/~rjmh/Papers/whyfp.pdf
      > "Formal proof isn't testing, testing isn't formal
      > proof..." ... Proof by test is hard -- you need to
      > test all conditions, through all branches!
      > Proof will eventually win.
      > Optimally, we can use multi-paradigmic programming
      > languages or paradigms that would compliment
      > each other at different levels of scale:
      > e.g. Haskell (through monads), Curry, Mozart,
      > LISA, etc.
      > http://www.informatik.uni-kiel.de/~mh/curry/
      > http://www.mozart-oz.org/
      > http://lisa.sourceforge.net/
      > Acceptance tests on the other hand will always be
      > needed -- we still much prefer to have them done
      > by the user interacting with the programmer, through
      > repeated interactions, rather than by automation.
      > i.e. we _still_ prefer people interactions over
      > processes and tools, sounds familiar?
      > - Mike
      > To Post a message, send it to:
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      > Your use of Yahoo! Groups is subject to

      Yahoo! Groups Sponsor
      To Post a message, send it to:
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to the Yahoo!
      Terms of Service.
    • Mike Beedle
      ... From: Fabian Ritzmann [mailto:usefri@gmx.net] ... Oh, I don t know -- we are still sort of on topic. ... We call tests by the user acceptance tests or
      Message 37 of 37 , Jun 6, 2003
        -----Original Message-----
        From: Fabian Ritzmann [mailto:usefri@...]
        > Need to bring this back on topic for this list. :-)

        Oh, I don't know -- we are still sort of on topic.

        > --- Fabian Ritzmann <usefri@...> wrote:
        > XP as I understand it uses unit tests and system
        > tests, unit tests for unit testing and system tests for
        > whatever the users want to test, including quality
        > aspects like performance, reliability, etc.

        We call tests by the user "acceptance tests" or ATs.

        I think this is a valid definition across XP and
        Scrum but I don't know if other agile methods call
        them the same way.

        self wrote:
        > The combination is very powerful:
        > * test as _specification_ from Test-First, and
        > * program as executable _specification_ from
        > functional programming
        > Both strategies drive development more into the
        > quantifiable _what_ space, much more than worthless
        > "exhaustive requirements documents" or "models".
        > Perhaps, this is what we need to concentrate in
        > software architecture -- in patterns that tell us
        > _what_ to program and that are executable,

        Fabian wrote:
        >The principle problem is that provable (and executable)
        >specifications don't help if the specification is wrong.
        >And we all know that specifications always change,
        >that's why we do Scrum or another Agile development
        >method. Of course that shouldn't keep anybody from
        >improving the way we are programming these days.

        True. In our view, the need for acceptance tests
        conducted through people-2-people interaction
        never goes away for the exact reasons you list
        (and regardless the programming styles used):

        - making sure that the specification is not wrong
        - making sure that we keep up with changes
        for the specification
        - making sure that the user experience is
        comfortable i.e. timely, convenient, beautiful, etc.

        It is just easier, faster and even more economical
        in some paradigms of programming to do the above
        3 things,

        - Mike
      Your message has been successfully submitted and would be delivered to recipients shortly.