RE: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.
In the early 1980s, Harlan Mills, Professor of Computer Science at the
University of Maryland AND and, at the same time and an IBM Fellow, created
a course based upon a his book "The Calculus of Programming." Freshman got
credit for the problem if it ran the first time they tried to compile it,
zero credit otherwise -- typical CS programming problems, n-digit
multiplication, n-column text justification, self-replicating code,
etc. They used a subset of Pascal, CF Pascal (Character File
Pascal). The only data-type was a character, the only structure/record
type was a file.
In a seminar I attended, Mills said they gave the same problems to grad
students who could use the full version of Pascal. The grad students were
not able to get it right the first time. This lead to the obvious
questions about robust versus simple languages and freshman vs grad
students as programmers.
When I was in school, I had a prof who insisted on compile reports from the
computer center (mainframe-based) and deducted from our score for excessive
compile/run attempts. Excessive was more than 2, more than 4 meant zero
credit (actually negative credit -- we had to get one other project done
with 1 compile/run or it REALLY hurt grades).
Years later when I took over a project for CSC that was 8 months behind
schedule, I insisted that successful test reports were required before the
code could be committed to the production base -- unit, integration, build,
and system testing. Project team objected -- but, the end result: we
delivered 1 month late (there is a limit to how much you can make up ;-))
and it worked, first time.
Bottom line... I agree, there was an economic component to early
"test-first" because of mainframe costs. There was also an underlying
frustration, with some people, about overall code quality -- I believe that
was _part_ of the basis for Dijkstra's "Goto Considered Harmful" letter and
the resulting structured programming movement: economic AND the inherit
belief that it had to be better. Later, fueling the effort were Capers
Jones metrics that showed costs escalated by a factor of 10 the later the
bug was caught in the SDLC.
At 12:49 PM 6/4/2003, David J. Anderson wrote:
>Geesh Mike! C++ in 1986 - you have my sympathy. The
>first time I saw it was in 87 or 88 and it was early
>On a more serious note - the "test first" concept was
>driven out of economics - the high cost of computer
>I knew a guy in the early 1990s who ran the OS/2
>device driver support for IBM EMEA. In his early
>career in the 60s he would have been fired if his code
>require more than 5 attempts to compile because
>hogging the compiler was anti-social. Hence, early
>developers learned to write stuff that worked first
>Even when I was at college we were made to submit
>'desk checks' i.e. manual hand-written test and
>execution at the function level (unit tests) before we
>submitted programs for marking. We were meant to have
>done the desk check before the compiling but there was
>no one to audit that we actually did.
- -----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