Motivation of software professionals

[Arved Sandstrom]

Aren't some programs released with known defects?

Absolutely. To me if a program comes with a clear list of known defects,
with description, that's a sign of maturity. Essentially the set of
known defects simply reduces the working functionality of the program -
if you can form an educated opinion about what that working
functionality is then you're OK to make a decision as to whether or not
it's suitable for the desired purpose.

Applied to what is most likely a branch of mathematics or applied to the
law?

Applied to the law. Don't get me wrong, I'm not saying the law is like
this now. It's not.

I think this may be part of an ongoing controversy. Here's a taste of
what's coming.
http://www.tampaflduilawyer.com/Defenses/DUIBreathTest.aspx (Look for
"Throughout the State of Florida, DUI defense attorneys are demanding
that the State of Florida provide the source code") and there's this:

"Reasons Why Production of the Source Code is Necessary"
"7. # The extent that known and unknown flaws in the program affect the
accuracy of the test results."

LR

And to my way of thinking, what's wrong with that? Although in this case
it seems like the fault, if any, would lie more with the purchaser.
Since we currently don't have any widespread mechanisms for certifying
and guaranteeing software, it's up to purchasers to exercise due
diligence *when they can*. I think it's unreasonable to expect private
individuals to be able to test software before purchase, but a
government certainly ought to be able to arrange for thorough testing
and inspection before they decide to buy an application.

AHS

 

[Arved Sandstrom]

On 12 Feb, 22:37, Arved Sandstrom <[email protected]> wrote:

[ SNIP ]

There used to be a lot less free stuff available, and it was
worse. (It doesn't make sense to me, either, but those are the
facts.)


Clearly. The problem is that most commercial firms don't do
that.

Right, and that's because usually the _only_ difference between free and
commercial software right now is the price. Paid-for software doesn't
come with any more guarantees or support than the free stuff does; in
most cases you actually have to pay extra for support packages.

In effect the commercial software is also crappy because we do not hold
it to a higher standard. I believe that a well-thought-out system of
software certifications and hence guarantees/warranties will lead to a
saner market where the quality of a product is generally reflected in
its cost.

Someone with a "glass is half-empty" perspective on this might bemoan
the fact that the higher cost would be all about absorbing the cost of
recalls and lawsuits and what not; I think the other view, that the
higher cost reflects the higher quality, and that you will expect
_fewer_ recalls and lawsuits, is just as valid, if not more so.

I think that part of the problem is that a mistake in a program
will affect every instance of the program. Most recalls for
cars, on the other hand, only affect a small subset of the total
production.

Is there any reason to believe that, in a more mature and professional
software development ecosystem, that the percentage of *total* recalls
of software would be excessive? Most software programs I have to work
with do not have show stopper bugs, and realistically do not need to be
"recalled". Generally they have localized bugs that have workarounds or
that you get a patch for. If the software was of quite high-quality in
the first place then the number of these lesser defects is not going to
sink a software shop.

AHS

 

[Lew]

Logically, I think that most of the techniques necessary for
making really high quality software would be difficult to apply
in the context of a free development. And at least up to a

Nonsense. Free software has a much higher rate of adoption of best
practices for high quality than for-pay software does.

You say so, too. It's the "logically" with which I take issue. That
free software uses the best techniques and has the highest quality in
the marketplace is entirely logical, in addition to being an observed
fact. You just have to avoid false assumptions and fallacies in reasoning.

point, they actually reduce the cost of development. So
theoretically, the quality of commercial software should be
considerably higher than that of free software. Practically,
when I actually check things out... g++ is one of the better C++
compilers available, better than Sun CC or VC++, for example.
Valgrind is at least as good as any of the commercial memory
checkers under Linux. And Subversion is at least as good as any
of the version management tools, excepted ClearCase (and the two
really address different models of development).

ClearCase is an unwieldy pig. You hold that up as an example of high
quality?

Admittedly, it's better than a lot of other version-control products,
but not nearly as good as the free ones.

There used to be a lot less free stuff available, and it was
worse. (It doesn't make sense to me, either, but those are the
facts.)

No, they're not the facts. Since the beginning of free software, much
of it has been very high quality. I doubt very much that the ratios
have changed much, or if they have, perhaps you could substantiate your
"facts".

I don't dispute that there used to be a lot less free software, insofar
as there used to be a lot less software of any description. It's your
undefined use of "worse" without evidence that I dispute.

I think that part of the problem is that a mistake in a program
will affect every instance of the program. Most recalls for
cars, on the other hand, only affect a small subset of the total
production.

A mistake in a car model enough to effect a recall affects every
instance of that model. Bugs in software, OTOH, affect only a small
subset of the total production of software.

You haven't been paying much attention to the news lately, have you?

 

[Seebs]

Logically, I think that most of the techniques necessary for
making really high quality software would be difficult to apply
in the context of a free development.

They might be hard to apply, but consider that a great deal of free
software is written without idiots saying "you need to get this done sooner
so we can book revenue this quarter to please shareholders". It's also
often written by particularly good developers, who care about their code.

It is also probably an influence that free software writers expect the
code itself to get feedback, not just the behavior of the application. I
have submitted bug reports about poorly-expressed code, not just about
code which didn't work.

And at least up to a
point, they actually reduce the cost of development. So
theoretically, the quality of commercial software should be
considerably higher than that of free software.

Again, I don't think there's actually any force driving that. The benefits
of well-written software are significant enough that it is likely worth it
to some people to improve software they have access to, and if it's worth it
to them to do that, it costs them virtually nothing to release the
improvements.

Free software often ends up with the best efforts of hundreds of skilled
programmers, with active filtering in place to keep badly-written code from
sneaking in.

And Subversion is at least as good as any
of the version management tools, excepted ClearCase (and the two
really address different models of development).

If you are implying that CC is actually usable to you, that marks a first
in my experience. No one else I've known has ever found it preferable
to any of the open source tools, of which git is probably currently the
most elegant.

I think that part of the problem is that a mistake in a program
will affect every instance of the program. Most recalls for
cars, on the other hand, only affect a small subset of the total
production.

Another issue is that, if you give away open source software, people can
modify it. If you modify my code, and your modification is not itself
buggy, and my code is not itself buggy, but your modification causes some
part of my code not to work as expected, whose fault is that? This kind
of thing is a lot more complicated with code than it is with physical
objects. You don't have a million people using a bridge, and a couple
hundred thousand of them are using the bridge recompiled for sports cars,
and another couple hundred thousand are running it with a third-party
tollbooth extension.

-s

 

[Seebs]

Right, and that's because usually the _only_ difference between free and
commercial software right now is the price. Paid-for software doesn't
come with any more guarantees or support than the free stuff does; in
most cases you actually have to pay extra for support packages.

Could be.

In effect the commercial software is also crappy because we do not hold
it to a higher standard. I believe that a well-thought-out system of
software certifications and hence guarantees/warranties will lead to a
saner market where the quality of a product is generally reflected in
its cost.

That might seem "saner", but again, the market is massively improved by
free stuff at the baseline.

Look at it this way: Would science improve if you were guaranteed that
for-pay versions of the Periodic Table were "better" than free ones? No.
It turns out that it's much better for everyone to have basic information
be completely free.

The closer you get to infrastructure being free (or paid for at a cultural
level rather than by individual users), the better everything else works.

Operating systems and compilers are infrastructure. More things are becoming
infrastructure-like with time.

Furthermore, commercial software has strong incentives to be badly-written
or poorly-designed. Think about IM protocols. What IM protocols have been
best designed? The ones that didn't feel a need to be "proprietary". Meaning
the ones designed explicitly with intent to be free and open. And not to
necessarily provide for a viable commercial business model.

Software is counter-intuitive economically. If you try to make it conform
to the economics of things which can be scarce because each instance costs
additional money, you'll cripple it.

Is there any reason to believe that, in a more mature and professional
software development ecosystem, that the percentage of *total* recalls
of software would be excessive? Most software programs I have to work
with do not have show stopper bugs, and realistically do not need to be
"recalled". Generally they have localized bugs that have workarounds or
that you get a patch for. If the software was of quite high-quality in
the first place then the number of these lesser defects is not going to
sink a software shop.

It won't if they're making substantial money. It would sink the
infrastructure work, though.

-s

 

[Brian]

The problem is that we already have copious amounts of turgid
broken crap available commercially. I don't see why adding free
software to the mix changes anything.

Logically, I think that most of the techniques necessary for
making really high quality software would be difficult to apply
in the context of a free development. And at least up to a
point, they actually reduce the cost of development.

I'm not sure what you are referring to, but one thing we
agree is important to software quality is code reviewing.
That can be done in a small company and I'm sometimes
given feedback on code in newsgroups and email.

So
theoretically, the quality of commercial software should be
considerably higher than that of free software. Practically,
when I actually check things out... g++ is one of the better C++
compilers available, better than Sun CC or VC++, for example.

Maybe now that Sun CC and VC++ are free they'll improve.
I'm not sure about Sun CC, but guess that it is free with
Open Solaris. Still I'm not comfortable with g++'s foundation.
I would like to think that VC++, written mostly in C++, is at
least able to produce a draw when up against g++.

There used to be a lot less free stuff available, and it was
worse. (It doesn't make sense to me, either, but those are the
facts.)



I think that part of the problem is that a mistake in a program
will affect every instance of the program. Most recalls for
cars, on the other hand, only affect a small subset of the total
production.

That may be a reason why an on line approach makes sense.
Since you haven't shipped out instances of the program,
just make sure the instances that exist on your servers
are corrected. The other way, a court in a distant country
might hold you liable if some customers didn't receive a
message that they should update their copy.


Brian Wood
http://webEbenezer.net
(651) 251-9384

 

[spinoza1111]

Hi all,

I am doing a research about motivation in software development, the
most efficient practices to motivate software engineers, their
popularity, etc.

As a part of the research, I am doing an online survey for software
engineers and managers in software development. It takes just several
minutes and filling it is a good opportunity to share your opinion
about the motivation practices being used in the software industry
today:http://ask.wizefish.com/en/MotivationSurvey.aspx

Anyone who does the survey and leaves any contacts will be sent the
results.

Also, if someone is running a web site or blog dedicated to any aspect
of software development we can do some link exchange.

Regards,
Stefan Kiryazov

(Sigh)

To understand software professionals you have to understand software.

Why do psychologists and MBAs not understand that to really do an
adequate job at "studying" a fully huamn endeavor both from the
standpoint of decency-towards-others and mere truth, they have to do
what (some) anthropologists call "thick description" and also
"participant observer"?

Anthropologist Diane Vaughan successfully studied a technical
phenomenon: the crash of the Challenger Space Shuttle. She did so as a
participant observer and using thick description, not questionnaires
with all sorts of hidden bias, including the basic bias of a
questionnaire: the people who respond to it are the sort of people who
actually like answering questionnaires.

 

[LR]

The "standard" life of a railway locomotive is thirty or fourty
years. Some of the Paris suburbain trainsets go back to the
early 1970's, or earlier, and they're still running.

Do you happen to know if they've undergone any engineering changes over
those 40 years for safety or performance enhancements?

With worn/damaged parts replacement how much of the original equipment
remains? Wheel sets, motors, controls, seats, doors, couplers,
windshields, etc. all get inspected and replaced on schedule.

Not all locomotives last 40 years.

Design flaws can contribute to a shorter life. For example the Erie Triplex.
http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/triplex/triplex.htm

Although design flaws played a part in the death of the Jawn Henry, I've
heard that N&W's business was undergoing changes and undercut the
companies desire to invest in coal fired power.
http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/nwturbine/nflkturb.htm


To continue with our locomotives, the replacement of coal fired steam by
diesel and electric (No, no, not this one:
http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/swisselec/swisselc.htm
) power was largely driven by maintenance cost, the sort that replaces
the lubricating oil, not the kind that replaces faulty brake systems,
although this played a role too. It's nice to be able to buy parts OTS
if you need them rather than have a huge work force ready to make parts.

I think ultimately the RRs asked themselves if they were in the
locomotive business or the transportation business.

LR

 

[Keith Thompson]

They might be hard to apply, but consider that a great deal of free
software is written without idiots saying "you need to get this done sooner
so we can book revenue this quarter to please shareholders". It's also
often written by particularly good developers, who care about their code.

[...]

I'm not convinced that the majority of free software is of
particularly high quality. But I think that most free software
that's sufficiently popular that you or I have heard of it does
tend to be of high quality. There are (at least) two effects here:
good free software tends to become popular, and useful free software
attracts good developers. The latter effect is less pronounced
in non-free software; however much I might like some proprietary
software package, I'm not likely to switch jobs so I can work on it.

But if you looked at the universe of free software, I'd be surprised
if Sturgeon's Law didn't apply (90% of everything is crud).

 

[Seebs]

I'm not convinced that the majority of free software is of
particularly high quality. But I think that most free software
that's sufficiently popular that you or I have heard of it does
tend to be of high quality. There are (at least) two effects here:
good free software tends to become popular, and useful free software
attracts good developers. The latter effect is less pronounced
in non-free software; however much I might like some proprietary
software package, I'm not likely to switch jobs so I can work on it.

But if you looked at the universe of free software, I'd be surprised
if Sturgeon's Law didn't apply (90% of everything is crud).

Sure.

But there's one other huge amplifying effect:

You can read the source so you *know* whether or not it's any good. That
helps a lot. The bad stuff tends to never go anywhere (see our spammer
from last fall with his Unix daemon utility), while the good stuff tends to
do quite well indeed (e.g., Rails).

-s

 

[Brian]

Sure.

But there's one other huge amplifying effect:

You can read the source so you *know* whether or not it's any good.  That
helps a lot.  

I think its helpful to be able to read code generated
by a compiler. I'm not talking about assembly
although that is helpful, but higher-level code.
In C++ due to a number of language features it's
easy to misunderstand what you are reading. If you
are having a problem and need to research the cause,
reading the later output can help detect the problem.

In my case, I have both open source code --
http://webEbenezer.net/build_integration.html --
and closed source code. The output from the closed
source code is also open source.


Brian Wood
http://webEbenezer.net
(651) 251-9384

 

[Arved Sandstrom]

[ ... ]

Exactly. Engineering is about measurable outcomes, quantification.
What's the equivalent of "this building can withstand a quake of
magnitude 7.5 for 30 seconds" in software? Can any of us state "this
software will stand all virus attacks for 12 months" or "this software
will not crash for 2 years, and if it does your loss won't exceed 20% of
all digital assets managed by it" ?

Your analogy is fatally flawed, in quite a number of ways.

First of all, a particular piece of software is only one component in
a much larger system of both hardware and software -- where the final
system is generally designed and assembled by a somebody who's not an
engineer at all. What you're asking for isn't like a warranty on a
building. It's more like asking a vendor of steel beams to warrant
that any possible building of any design will withstand earthquake X
as long as it includes this particular component.

[ SNIP ]

And to continue the analogy, what would be reasonable to ask for is that
the steel beam vendor warrant his steel beams provided that they are
properly used according to his specifications. We can actually do that
for software components as well.

AHS

 

[Arved Sandstrom]

Sure.

But there's one other huge amplifying effect:

You can read the source so you *know* whether or not it's any good. That
helps a lot. The bad stuff tends to never go anywhere (see our spammer
from last fall with his Unix daemon utility), while the good stuff tends to
do quite well indeed (e.g., Rails).

-s

*In theory* you can read the source. However, not many professional
developers actually have the time to assess open source code quality by
doing code inspections. I myself tend to go with reviews, previous
experience of software by the same people, experience of older versions
of the same program, and the provided documentation.

And I've used a number of programs for which the source was available
where problems caused us to dive into the code. The code passed visual
inspection, no problem...but it still had defects.

AHS

 

[Seebs]

*In theory* you can read the source. However, not many professional
developers actually have the time to assess open source code quality by
doing code inspections. I myself tend to go with reviews, previous
experience of software by the same people, experience of older versions
of the same program, and the provided documentation.

I do too, but the moment I have to look at something, I can start evaluating
it. I pitched a several-week project to management on the basis that I'd
read the code of a component we were using, and concluded from quality
issues where the code worked but wasn't pretty that it would not be worth it
to try to fix the cases where it didn't work.

And I've used a number of programs for which the source was available
where problems caused us to dive into the code. The code passed visual
inspection, no problem...but it still had defects.

Oh, sure. Nearly all code still has defects. The questions that are more
interesting are how easy it will be to work on the code, or how likely it
will be that fixing one defect will reveal others.

-s

 

[Öö Tiib]

Nonsense.  Free software has a much higher rate of adoption of best
practices for high quality than for-pay software does.

You say so, too.  It's the "logically" with which I take issue.  That
free software uses the best techniques and has the highest quality in
the marketplace is entirely logical, in addition to being an observed
fact.  You just have to avoid false assumptions and fallacies in reasoning.

Not sure what you mean. There are no such logical binary connection.
Opposite is as easy to observe.

Just download few C++ code-bases at random from places like
sourceforge.net and review them. One produced by using good techniques
is really hard to find there. Most code there has quality so low that
it would be unthinkable in professional software house to pass QA peer
review with it. It is easy to logically explain since most of it is
hobby of non-professionals who find software development amusing or
professionals of other language who learn C++ as hobby.

Results are slightly better with larger and more popular open source
products but that is often thanks to huge tester and developer base
and not good techniques used.

In best shape are open source projects that are popular and where
commercial companies are actively participating since they need these
for building or supporting their commercial products. Again it is easy
to see how the companies are actually enforcing the techniques and
quality there and it is likely that the companies use even higher
standards in-house.

Worst what i have seen is the code written by in-house software
department of some smaller non-software companies but that is again
easy to explain by workers of that department obfuscating their work
to gain job security.

So all things have logical explanations and there are no silly binary
connections like free = quality and commercial = lack of quality.

 

[Malcolm McLean]

Most software programs I have to work
with do not have show stopper bugs, and realistically do not need to be
"recalled".

I'm using Matlab at the moment. It seems to crash about once every two
days. A bug in a C subroutine will also take down the whole system.
That's irritating but liveable with. However what if the results of my
scientifc programs have small errors in them? No one will die, but
false information may get into the scientific literature. If I was
using it for engineering calculations, someone might die. However the
chance of a bug in my bespoke Matlab code is probably orders or
magnitude greater than a bug in matlab's routines themselves. So does
it really matter?

 

[Arved Sandstrom]

I'm using Matlab at the moment. It seems to crash about once every two
days. A bug in a C subroutine will also take down the whole system.
That's irritating but liveable with. However what if the results of my
scientifc programs have small errors in them? No one will die, but
false information may get into the scientific literature. If I was
using it for engineering calculations, someone might die. However the
chance of a bug in my bespoke Matlab code is probably orders or
magnitude greater than a bug in matlab's routines themselves. So does
it really matter?

This is a really good point. I've worked with programs that deal with
health information, others that deal with vital statistics
(birth/death/marriage etc), others that deal with other public records
(like driver licensing and vehicle registration). I've also spent quite
a few years (not recently) writing programs that manipulate scientific
data (primarily oceanographic data).

In the case of the latter (the oceanographic data), naive acceptance of
my program output by a researcher might have led to professional
embarrassment, or in the worst case it could have skewed public policy
related to fisheries management or climate science. Realistically though
we had so many checks at all stages that the chances of errors were minute.

Data integrity defects, or the hint thereof, in the driver's
license/vehicle registration/vital statistics applications certainly
cause(d) a lot of sleepless nights, but the effects here are individual,
and depending on who you are talking about tend to confine themselves to
career damage and again embarrassment, and some wasted time and money,
but rarely anything truly serious.

Data integrity errors in health information are ungood. Period.

In the first case (oceanographic data processing) occasional crashes of
programs were irrelevant. All the software was custom, and it's not like
it had to be running 24/7. In the case of the motor vehicle registry
systems, or the vital statistics systems, it does need to be running
24/7 (e.g. the police need to run plates at 3 AM as much as they do at 3
PM), but ultimately a crash is still only an embarrassment. In the case
of health information (e.g. a system that paramedics can use to query
MedicAlert data while on a call), a crash is unacceptable.

Depending on the application you can describe the impact of both data
integrity errors, and downtime due to crashes (or extreme sluggishness).
All this stuff really needs to be part of system requirements (not just
software requirements). I've noticed too that many programmers tend to
concentrate on issues like uptime, performance and business logic, but
completely or substantially ignore matters like encodings, data type
conversions, data value sanity checking and invariants, to mention a
few. IOW, they do not have a good understanding of the data.

Ultimately what is tolerable obviously varies, both with respect to
system availability and also with respect to data integrity. If we have
defects then we are guaranteed to have defects in both areas. Personally
I believe that with respect to the latter - data integrity - that
software developers at large could learn a lot from scientific
programmers, but good luck with that one.

AHS

 

[James Kanze]

[ SNIP ]

There used to be a lot less free stuff available, and it was
worse. (It doesn't make sense to me, either, but those are
the facts.)
Clearly. The problem is that most commercial firms don't do
that.

Right, and that's because usually the _only_ difference
between free and commercial software right now is the price.
Paid-for software doesn't come with any more guarantees or
support than the free stuff does; in most cases you actually
have to pay extra for support packages.

In effect the commercial software is also crappy because we do
not hold it to a higher standard. I believe that a
well-thought-out system of software certifications and hence
guarantees/warranties will lead to a saner market where the
quality of a product is generally reflected in its cost.

I think you're maybe confusing cause and means. I'm not
convinced that certification of professionals is necessary; I am
convinced that some "implicit" warrenties are necessary, and
that if an editor trashes my hard disk, the vendor of the editor
should be legally responsible.

Certification, in practice, only helps if 1) the vendor is
required to use only certified people in the development
process, 2) the certification really does verify ability in some
way, and 3) the vendor allows the certified people to do things
in the way they know is correct. In practice, I don't think 1
and 3 are likely, and in practice, there are plenty of capable
people around today, without certification, who would do a very
good job if the vendors would ask them to do it, and structure
their organization so they can. I've worked in places where
we've produced code with quality guarantees, and where we've
produced we've produced code which met those guarantees. And
the people there weren't any more (or less) qualified than the
people I've seen elsewhere. The problem isn't the competence of
the practitioners (which is the problem certification
addresses), but the organizations in which they work.

Someone with a "glass is half-empty" perspective on this might
bemoan the fact that the higher cost would be all about
absorbing the cost of recalls and lawsuits and what not; I
think the other view, that the higher cost reflects the higher
quality, and that you will expect _fewer_ recalls and
lawsuits, is just as valid, if not more so.

The lawsuits are going to come. The insurance companies are
convinced of it, which is why liability insurance for a
contractor is so expensive (or contains exclusion clauses,
because the insurer doesn't know how to estimate the risk).

 

[James Kanze]

Nonsense. Free software has a much higher rate of adoption of
best practices for high quality than for-pay software does.

Really. I've not seen any free software which adopted all of
the best practices. In my experience, some of the best
practices require physical presense, with all of the developers
having offices in the same building. (The experiments I've seen
replacing this with email and chat haven't turned out all that
well.) This is far more difficult for a free project to achieve
than for a commercial one.

You say so, too.

What I said is that apparently, many commercial shops don't take
advantage of their advantages. For example, one of the key
factors in developing high quality software is communication.
And communication is, or should be, easier when everyone works
in the same plant. Never the less, one continually hears
stories about lack of communication in such cases; about
internal competition even leading to misinformation. The
potential in a commercial organization is higher, but it's clear
that many such organizations aren't using it (and that a few
free projects are using everything they can).

It's the "logically" with which I take issue. That free
software uses the best techniques and has the highest quality
in the marketplace is entirely logical, in addition to being
an observed fact. You just have to avoid false assumptions
and fallacies in reasoning.

First, free software doesn't have the highest quality. When
quality is really, really important (in critical systems), you
won't see any free software. I'm certain that no free software
project is certified at SEI level 5, and from what I've seen,
very few reach SEI level 2. Some commercial organizations (one
or two) are certified at SEI level 5, and I've worked for some
that were around level 3. Most of the ones selling the software
we usually use (e.g. Microsoft, Sun, etc.) are still at level 1,
however.

ClearCase is an unwieldy pig. You hold that up as an example of high
quality?

ClearCase uses a different model than any of the other version
management tools I've used. In particular, the model is
designed for large projects in a well run shop---if your
organization isn't up to par, or if your projects are basically
small (just a couple of people, say up to five), ClearCase is
overkill, and probably not appropriate. If you're managing a
project with five or six teams of four or five people each, each
one working on different (but dependent) parts of the project,
and you're managing things correctly, the ClearCase model beats
the others hands down.

My statement wasn't really clear, however: it's the ClearCase
model which makes it the best choice in such cases, not the
quality of the software. I've no reason to belive that
ClearCase is developed using a better methodology than anything
else.

Admittedly, it's better than a lot of other version-control
products, but not nearly as good as the free ones.

As one of the free ones, in terms of quality, perhaps. The
model is different, so it's very difficult to compare. In cases
where the ClearCase model is preferrable, ClearCase is stable
enough that you're better off using it than something supporting
a different model.

No, they're not the facts. Since the beginning of free
software, much of it has been very high quality. I doubt very
much that the ratios have changed much, or if they have,
perhaps you could substantiate your "facts".

Did you actually try using any free software back in the early
1990's? Neither Linux nor g++ were even usable, and emacs (by
far the highest quality free software), it was touch and go, and
depended on the version. Back then, the free software community
was very much a lot of hackers, doing whatever they felt like,
with no control. Whereas all of the successful free software
projects today have some sort of central management, ensuring
certain minimum standards.

I don't dispute that there used to be a lot less free
software, insofar as there used to be a lot less software of
any description. It's your undefined use of "worse" without
evidence that I dispute.

I was there. For the most part, free software was a joke.

A mistake in a car model enough to effect a recall affects
every instance of that model. Bugs in software, OTOH, affect
only a small subset of the total production of software.

I'll admit that that paragraph is just speculation on my part.
And it's speculation with regards to the motivation for not
providing guarantees: the real issues are far more complex.

You haven't been paying much attention to the news lately,
have you?

The percentage of Toyota's production which is affected is
considerably smaller than what would happen if Microsoft were
required to recall Windows.

On the other hand, of course, software allows user installable
patches (what Microsoft does when there is a critical bug),
where as with a car, you generally have to bring it into the
shop, at much greater cost to the manufacturer (and to you).

 

[Malcolm McLean]

The problem isn't the competence of
the practitioners (which is the problem certification
addresses), but the organizations in which they work.

Also the problem itself. It is impossible to test MiniBasic on all
possible different paths all possible scripts could take it through,
for example. (I wrote little test scripts to test each statement
individually when developing it). On the other hand a game like
"Defender" has a very limited set of user inputs.