RE: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.
- Thanks for remining me of the name "Zortech". I was
straining to come up with it and just couldn't find
it. Lost in the chemical network excuse for a memory I
keep inside my head.
I lived in an "Objective C" snobland populated with
Smalltalk academics during those years. Hence, there
was a tendency to look down on C++. At the time, I was
a 68000 programmer and was busy inventing object
oriented macros to get re-use and repeatability.
--- Mike Cohn <mike@...> wrote:
We were doing CFront back then. C++ didn't get fun
until Zortech in 88/89.
Yes, we did "test first" because our training
environment was simulating a
high-cost environment. We were limited to 3 compiles a
day. We had to submit
our jobs to a simulated unfriendly IT department and
would get printouts
back hours later with our compile errors.
As you say, desk-checking was a big part of what we
did prior to submitting.
Fortunately, I only had to live in those dark-ages for
3 weeks and then I
went back to a PC and C/C++ and 400 compiles a day!
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
- -----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