Re: elegant way to determine if something is defined

On Mon, Feb 11, 2013 at 8:38 AM, Carlo E. Prelz <[e-mail]> wrote:
>         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 ([e-mail]):
>
>> 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=C3=B6del, 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...



Ay! Ay! Ay! You all have launched off into one my favourite rabbit
holes. Alas, I am in the midst of trying to get a release out and not
quite free to join in.

Can I just say, you're both right? Carlo's methodology is how I
learned functional programming: building elements that always work,
and are constantly under test as the system grows and progresses.

Robert's methodology is forward-loading the specification based on the
third of what I refer to as the 3 golden questions in determining
outcomes:
1. what do you want?
2. what will having that do for you?
3. how will you know when you have it?

The first two are what one asks up front for figuring out what problem
you'll solve, or what further ability you'll enable. The last one,
though, is a bit different and how it is applied to software
development is precisely TDD/BDD. The modern versions of TDD/BDD can
be invaluable in fleshing out the requirements and design for your
product when you don't necessarily understand it completely, and need
to build it with others who will also use your software and tests to
build their parts.

The defining factor, for me, was the amount of moving parts and
communication among the developers. In the case of many a modern
software project, sadly, many developers don't realize that what they
are writing are communication instruments: the software must speak to
those who come along later and need to understand it to fix it,
enhance it and interact with it. Unfortunately, sometimes (how often
I'm not sure) the expectation is that one just does what one can
without understanding that fantastic Gilgamesh you wrote, and so in
the interests of expediency and that management that will sort things
out and can't, stuff breaks.



It's never going to be entirely one or the other; a set of components,
constantly under scrutiny while the project progresses can work well
when the project is at least well-known enough to be able to provide
well-contained components with well-defined and unchanging interfaces;
while a set of specification-driven-by-test can provide a means of
distributing development in parallel where the highest fidelity
communications are possible, or aren't happening.

If given a team of unknown and varying skill, and/or broadly
distributed (and maybe especially if there are also culture, language,
and proficiency gulfs), I'd opt for the latter, even with the
understanding that it is imperfect and prone to error in itself.

Arggh, I cannot say what I want to in this short time. Please keep
this discussion going!