Re: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.
- --- Fabian Ritzmann <usefri@...> wrote:
Mike Cohn wrote:
>> Hmm, when you write HaskellUnit for us, I'llIt is a mind warping experience....
>> give it a try! :)
Whether you program in Haskell later or not or for
how long is irrelevant -- it will definitely change
the metric of how you evaluate "goodness" or
"fitness" for you programs and it will somewhat
change your programming _habits_ -- at least that's
what it did for me.
After learning functional programming, or worse
after learning functional-logical programming
i.e. Curry, Clips, etc.. one tends to develop
systems that are logical and/or functional even
when you are using imperative programming
languages i.e. Java, C++, etc. -- kind of like
writing OO programs in C.
We in fact use a layered architecture for our
servlet-based J2EE apps that tries to emulate
a logical-functional paradigm.
The result? We think a simpler, more elegant, higher
performance (through memoization) -- and
definitely more reliable system. But we are a little
biased ;-), of course.
> That's why the first programming course for CSYep, early mind warp in that direction is highly
> students at my former university has been based
> on a functional programming language for more
> than 10 years already. Best to teach it as early as
> You are testing quality with unit tests? MineSo you never run into a null pointer exception, or
> are entirely functional. They still improve quality
> but that's not what is tested. System quality
> is usually tested by integration and system tests.
unmanaged memory, or uncovered branches, or ugly
side effects in a test for an imperative program? :-)
Yes, I confess -- I use unit tests for both, system
and functional tests. But I agree, a _strong_ aspect
of units tests is also their mini acceptance test role
for the features of a component.
> What the world needs to accept is that declarativeFabian wrote:
> programming paradigms lead to a much higher
> quality to begin with because they avoid system
> errors and in many cases guarantee provability:
> Haskell, Clips, Prolog, Erlang, etc., etc.
> I thought about that, too, when I read MichaelThe combination is very powerful:
> Feathers' opinion that one should teach test driven
> development right from the beginning. I had
> been taught functional programming in the beginning.
* test as _specification_ from Test-First, and
* program as executable _specification_ from
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,
- -----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