SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 16 Feb 2003 17:50:31 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: In retrospect

Content Type: text/plain

Gregrory and Steven,

I wondered if and when the two of you would weigh in on the
subject. You have great faith in bug tracking systems
where I wonder how the bug managed to get "out there" to
begin with. Therein lies the difference between what occurs
today and what need not occur at all.

You see you are willing to accept and somehow perfect a
defect system for software when I'm trying to insure that
such defects will never see the light of day, having been
detected, and corrected prior to any release.

The purpose of test data lies in testing all possible paths in a
program with data that insures it does what it is supposed to
do and other data to insure that it does not what it is not
supposed to do. Probably as the last example of current bug
tracking and correcting methods would I choose Mozilla, which
like every other large project in open source, including Linux,
progresses at a pace which makes even a snail look fast.

If you have any faith in Deming's approach to quality control,
you know that the goal lies in the earliest detection of an
error and correction at its source. To be honest with you we
covered the three types of errors that a programmer can
make: syntax, semantics, and logic. To be even more honest
all these consist of writing errors. The final leap of honesty
here lies in admitting that all writing errors occur at data
entry, i.e. during the editing process.

The need then lies in detecting and correcting the errors as
closely to data entry as possible. We agreed that "really
smart" editors can detect syntax and semantic errors almost
immediately after data entry. That leaves us with only
detecting errors of logic.

How quickly can we detect logic errors? Then how quickly
can we correct them? When I submit a "build" to the
community for testing what can the testers do other than
input data values, even assuming that they are capable of
regressive testing, i.e. they have accumulated a large set of
test data?

Now let's think here for a second. If a set of regressive test
data exists, and there is reason to believe that sharable test
data qualifies as a candidate for open source, why would I
submit a build without performing regression testing? Just as
obviously I wouldn't but just as obviously if logic errors still
exist my test database is incomplete.

Moreover it is as subject to the dynamics of change as that
which it is supposed to test. The cost of maintaining it rivals
the cost of maintaining the software. No wonder the thought
of distributing that cost "out there" to beta testers is so
attractive.

The truth is you may be pursuing your own path in which no
one else has an interest. You have no beta testers. You need
a system in which they can provide no added value in terms
of testing. If you have such a system, no one needs beta
testers. If you don't need beta testers, you don't need bug
tracking or logging. You free up a whole hell of a lot of time
in which people can spend writing (and releasing) bug free
source code.

I'm confident that we could extend the same methods of logic
programming to the software involved with the chemical
processes Greg refers to. Those systems are control systems
involving feedback and responses to changes in the external
environment. Programs like HPCalc and Mozilla do not fall into
that class. Nearly all open source programs do not fall into
that class.

What I assert at the moment for the larger class of open
source programs is that it is possible to iteratively test it from
the inside out with rule-based data automatically generated
by the software. In the coming weeks as we come with an
increasing understanding of logic programming and its impact
on the ways we currently develop and maintain software our
differences should melt away. We all agree on proven fact.
The more proven facts we have in common the more we will
agree.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 16 | February | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.