Subject: Re: ways of funding
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Tue, 9 Nov 1999 13:06:36 +0900 (JST)

>>>>> "Craig" == Craig Brozefsky <craig@red-bean.com> writes:

    Craig> "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

    >> More important, CPAN does not supply proof of correctness with
    >> any of its modules.

    Craig> How much of NASA's software do you think is "proven
    Craig> correct" in a formal manner before it's blasted off the
    Craig> planet?

C'mon, I don't mean that seriously, as you obviously recognize.  Why
do you take it seriously?

Let's put it this way.  Would you dare use a VHLL that simply
downloaded a bunch of modules from CPAN and copied them into a big
script with some glue code you write, without looking at the code for
each module you hadn't looked at recently?  But that's exactly what
you do with libc, isn't it?  When was the last time in the course of
_building an application_ that you looked at libc code?  Or built a
substitute for an unusably buggy libc function?

So you save some coding time with CPAN modules, or any of the stuff
that gets published.  Big deal.  Coding time is a small fraction of
any project.  If you want to call _that_ "reuse", _I'll_ find another
word.  Reuse is not economically[1] important for itself; rather,
because it builds significantly stronger projects much faster.

    rn> I'll take a leap of faith, and further assert that scripting
    rn> languages get more reuse than do compiled languages.

    >> Not in my mission-critical apps, they don't.

    Craig> Mission-critical is such a narrow part of the market
    Craig> anyways, so I don't understand why you are basing your
    Craig> argument about the ability of Free Software to facilitate
    Craig> re-use on it.

All apps are mission-critical to somebody, for one thing.  And we
pretend to be better.  "With enough eyes, all bugs are shallow."
"Linux inside."  "Builds strong systems 12 ways."  We certainly don't
think we deserve Russ's epithet "Crap Software Movement."

But the real point is that good-enough software doesn't scale.  It's
not today's apps built out of a dozen of today's modules that matter.
It's the day after tomorrow's apps built out of a dozen modules each
built out of a dozen modules each built out of a dozen of today's
modules that matter.  Put that in your reliability calculus and tell
me you like what you see!  If you're very very lucky, that will only
be 144 times as buggy as today's app.  I think it's more likely to be
on the order of 1728 times as buggy as today's app.

    Craig> Also, this distinction between scripting and compiled langauges
    Craig> doesn't seem to make much sense.

"Are you talking to me?"

That was Russ's distinction.  My distinction was presence/absence of
static type checking which makes rapid prototyping and stuffing square
pegs with soft corners into flexible round tubes harder/easier.

    Craig> You seem to be confusing some psuedo-technical terms with
    Craig> actual software quality.

Of course I am.  _Because that's all there is._  Give me something
technical to work with, and I'll use it.  But you yourself insist that 
FSBs don't/won't do metrics.  ESR even says metrics are evil!

We've got a couple of studies that show that when geeks get access to
the source code for the utilities they use literally hundreds of times
a day they beat them to stiff peaks.  Ha!  If after nearly 20 years,
the GNU file/shell/textutils are not far more robust and efficient
than any proprietary vendor's product, something is seriously wrong.

We have _no_ studies that I or Steve McConnell (who is presumably
moderately well informed, cf IEEE Software, July/August 1999, p. 6)
know of comparing the development processes given similar products and
similar time constraints.  That's not your problem, but given that, I
don't see how either of us can claim to know "what quality is" better
than the other.

I do claim to be taking a conservative view.  Isn't that what a
business should do, too?  Optimism in business consists of taking
risks of big losses that are balanced by even bigger potential gains,
not of overestimates of the gains, that could be true if only we wish
hard enough.


Footnotes: 
[1]   Reuse as such is very important, but "sharing" is a better word
for that.  However, I am concerned not only with developers, but with
users, the majority of whom get no joy from this kind of sharing.  You 
know, the ones who pay the bills for FSBs.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."