From: "Carlo E. Prelz" <fluido@...>
Date: 2013-02-11T23:38:29+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 08:40:34 +0900

I hope you don't mind if I reply only to the points I think are most
important - the mail would grow to unmanageable dimensions if I
replied to everything, and the other readers would get bored.

Quoting Robert Klemme (shortcutter@googlemail.com):

> Well, yes.  But since you do test you obviously think that is a good
> thing to do.

I obviously do think it is good to shake my code a lot so that the
flaky points manifest themselves. And I developed a good sense for how
they manifest. Nothing that could be codified/automatized, I am
afraid.

> > Anybody who sincerely believes in this statement has not had enough
> > experience.
> 
> What's wrong with making that a goal?

Adopting impossible goals is very romantic. sometimes it is
impractical, but of course you are free to adopt any goal you
want. The problem arises when people think that, by adopting that
specific goal, they will actually obtain bug-free code. 

> 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
> same.)

"works always" and "has zero bugs" are equivalent statements. What I
state is that any non-trivial software package can be rendered
*virtually* bug-free by maintaining it long enough without changing it
too much. By that time, it will have become brittle (either unsuitable
to the hardware or unsuitable to the task, and very hard to change).

I further state that anybody who guarantees that a non-trivial new
software being delivered to the public will "work always" (or "has
zero bugs") is a shameless liar. There is no way you can guarantee
that.

Software has to be gently led through its first steps, and then
affectionately helped in growing and adapting to new needs. A software
package is a living creature, not a commodity.

> > 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.

Here is the point. It is a false confidence. You may have made errors
in the tests, for example. You'd need tests for your tests,
etc. etc. 

Or it may even be that you will face a situation that the creator of
the automated test system you use did not think about.

Have you read Douglas Hofstadter's book about G�del, Escher & Bach?
It has been one of the most important books I read in my formative
years...

> > I am afraid this cannot be bought by money, and cannot be certified by
> > certifications.
> 
> Yes, that's a management task.

It's the typical thing that cannot be imposed. Good luck,
management...

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)