[linux-elitists] What to do about cluebatting such companies, that require possibly *YEARS* old Distros

glen martin glenm@locutory.org
Wed Jan 26 13:45:24 PST 2005


On Wed, 2005-01-26 at 13:14, Rick Bradley wrote:
> Then again, I suppose we're talking about improperly administered
> environments almost by definition in this thread, so, um, carry on.

Well put. Indeed, for many of these systems it
seems the only spec of what they do is, well,
what they do. Regressing testing presumes you
have use cases and tests. Creating tests by
watching what the systems do with different
inputs doesn't work well either because, as
Parnas and others asserted, software systems
are discontinuous functions. Without testing
all permutations of input and state, one can't
reason well.

This isn't strictly true, of course, with access
to the code, because one can spot the inflection
points, but it is hard.

Ugh.

Aaron takes issue with the word 'improperly'.
It is a question of goals.  In a large telecom
manufacturer at which I once worked, tests were
fully automated and thorough. More people wrote
tests than wrote the system under test. This was
because for that environment bugs were simply
unacceptable period. There are other environments
that are the same: nuclear reactor control systems,
radiation therapy machines, etc. The economics don't
permit error. The word 'improperly' absolutely
applies in this sort of context.

For the rest of us, it is an optimisation
problem. Cost of defects vs cost of rigor at
initial development time.  Where this analysis
fails is that some tend to not consider the long
term cost of lack of rigor, in the effect of
poor specification and testing regimen on the
ability to later upgrade, update etc. But even
taking the long term costs into account, the
net present value of the maintenance problem
may not clearly exceed to nonlinear growth in
costs due to increasing development rigor.

glen





More information about the linux-elitists mailing list