RE: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.
- 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.
From: Mike Beedle [mailto:beedlem@...]
Sent: Wednesday, June 04, 2003 2:11 PM
Subject: RE: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for
Reviewers--They Don't Even Mention XP, Agile, etc.
> When the first programming course in a CSDavid M. wrote:
> curriculum uses Test Driven Development,
> we'll be teaching programming as we should.
>Bottom line... I agree, there was an economicMike C. wrote:
>component to early
>"test-first" because of mainframe costs.
> Yes, we did "test first" because our trainingMike C. wrote:
> environment was simulating a high-cost environment.
> I went for a 3-week COBOL training class outsideDavid A. wrote:
> Chicago and we were very definitely taught to write
> tests first.
> On a more serious note - the "test first" conceptTest-first makes more sense specially for
> was driven out of economics - the high cost of
> computer time.
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
quality to begin with because they avoid
system errors and in many cases guarantee provability:
Haskell, Clips, Prolog, Erlang, etc., etc.
"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,
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?
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- -----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:We call tests by the user "acceptance tests" or ATs.
> 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.
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.
> The combination is very powerful:Fabian wrote:
> * 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,
>The principle problem is that provable (and executable)True. In our view, the need for acceptance tests
>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.
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