From: "Carlo E. Prelz" <fluido@...>
Date: 2013-02-11T16:05:23+09:00
Subject: Re: elegant way to determine if something is defined

	Subject: Re: elegant way to determine if something is defined
	Date: lun 11 feb 13 05:30:30 +0900

Quoting Robert Klemme (shortcutter@googlemail.com):

> > While I do not use unit tests (which constitute
> > more code, and thus give you more occasions to drop in the occasional
> > bug or two), I make sure my code can be tested in its functionality
> > very often during development.
> 
> 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
process unrolls. When I wrote "my code can be tested," I meant that,
along the development phase, my code has to be executable all the
time: I verify every new feature as soon as I have added it, when its
function is fresh in my mind, then I move on, removing, or often just
commenting out, whatever code I had added for verification purposes.

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.

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
experience. I would redraft it as follows:

"After proper weaning, quality code WORKS almost all the time, the
interval between discovered bugs growing exponentially."

That's because we humans make errors, in all of our endeavours.
Writing code, writing test code, drafting 'best practices.' There is
no escape. G�del 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
illusion.

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. Then, the improbability of
the set of circumstances that trigger the bug can cause geometric
proliferation in interconnected systems. To have an idea about how
fragile interconnected system may be, have a look at this page:

http://en.wikipedia.org/wiki/2003_Italy_blackout

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.

I am afraid this cannot be bought by money, and cannot be certified by
certifications. 

> 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:
> http://baselinescenario.com/2013/02/09/the-importance-of-excel/

You are right about the catastrophic effects. But forget your hopes if
you dream of an error-free world - at any level.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)