On Mon, Feb 11, 2013 at 8:05 AM, Carlo E. Prelz [email protected]
That does not seem to make sense to me: why would you advocate testing
but avoid providing automation?
I did not advocate anything. I only described how my development
Well, yes. But since you do test you obviously think that is a good
thing to do.
From what I have read about automated tests, the goal the authors of
the various systems have is not so widely different from what I do. It
is the pretense to make these processes automatic that, according to
my very personal opinion plus experience, makes them hit far from the
center of the target.
Can you elaborate that? In what ways do they miss the target?
I recently came across a perspective employer who drafted a list of
so-called ‘software commandments.’ One of them reads:
“Quality code WORKS! All the time.”
Anybody who sincerely believes in this statement has not had enough
What’s wrong with making that a goal? I know, according to the
wording this is not a goal but written as a fact. But, as you say,
everybody who is in the business longer than a few days must know that
there are always bugs. (btw. “works” and “has zero bugs” are not the
I would redraft it as follows:
“After proper weaning, quality code WORKS almost all the time, the
interval between discovered bugs growing exponentially.”
That would be the case only if no new requirements came up, no new
features were added and only bugs fixed.
That’s because we humans make errors, in all of our endeavours.
Writing code, writing test code, drafting ‘best practices.’ There is
no escape. Gdel speaks clearly. The advocates of automated testing
demand a sizeable increase in programmers’ workload (a double codebase
to maintain, after all), and then transfer the authority to judge on
the health of the code to the set of tests being passed. This is an
I’d call it a trade off: you trade off developer time during initial
phase for bug fixing, customer support and SLA violation penalties.
All these systems, far from making code perfect, only push the bugs
further away in time.
The further away the bug is discovered, the more
catastrophic its consequences may be: first of all, the knowledge
needed to fix it may not be there anymore.
Which to me sounds like an argument for automated unit tests. With
those you can execute them any time and quickly after adding new
features or changing code. The helps discovering issues early.
In a nutshell, I believe that the tranquillity that is promised by any
of these automatic systems is false money. The PEOPLE who work
together have to engage their good will, and be willing to clean up
after their own mess. And to cultivate harmony. At that point, the
common practices grow spontaneously and quality ensues.
Of course that helps enormously. But automated tests give you the
confidence that the quality is at least as it needs to be.
I am afraid this cannot be bought by money, and cannot be certified by
Yes, that’s a management task.
That reminds me of a paper which made this distinction between
biological and technical systems: biological systems try to limit the
impact of an error to allow the whole system to keep going on while in
technical systems we want to make errors prominent so they are easily
caught and can be remedied. Because in technical systems errors which
go unnoticed can have catastrophic effects. See here for example:
You are right about the catastrophic effects. But forget your hopes if
you dream of an error-free world - at any level.
What makes you think I might dream of an error free world? I certainly