Motivation of software professionals

[Brian]

He doesn't even have to have done that much.  If he knows that
the brakes doen't work, and he lets you drive it, he's legally
responsible.

I have no problem with that. Some though believe that
if you give away a car and aren't aware of a problem
with the car, that you are still liable. I don't think
I'm obligated to have a car looked at by a mechanic
before giving it away. If it is safe to the best of my
knowledge, then I should just tell whoever wants the
car about it's history and encourage them to have the
car checked out.


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

 

[Arved Sandstrom]

Common sense has the interesting attribute that it is frequently totally
wrong.

I have published a fair amount of code which I was quite sure had at
least some bugs, but which I believed worked well enough for recreational
use or to entertain. Or which I thought might be interesting to someone
with the time or resources to make it work. Or which I believed worked in
the specific cases I'd had time to test.

It sounds like you're saying what I said, which is that publication for
an announced purpose - recreational use, proper operation in specific
defined cases, as a baseline for future work - is a statement that it is
fit for that purpose. If there are no qualifying statements (bug list,
READMEs etc), then the implication is that the exposed functionality of
the program is considered to work.

Either that or the author is so apathetic about his product that he
doesn't know about half the defects and can't be bothered to tell anyone
about the other half that he does know about.

I do believe that software will not cause harm *unless people do something
stupid with it*. Such as relying on it without validating it.

Validating it? That's all well and good if you're writing a program for
other developers. It is not something that you can expect average
computer users to understand or be capable of doing.

I don't agree. I think it is a reasonable *assumption*, in the lack of
evidence to the contrary, that the publication is a statement of *suspected*
fitness for use. But if someone disclaims that, well, you should assume that
they have a reason to do so.

Such as, say, knowing damn well that it is at least somewhat buggy.

[ SNIP ]

It has something to do with the nature of the disclaimer. If someone
specifically documents that such-and-such functionality doesn't work,
that's cool. I can live with that - that's normal. I have much less
tolerance for the blanket disclaimer that essentially states that
_nothing_ works, except when it does. Since no developer would actually
publish a product where they truly believed that nothing worked, these
blanket disclaimers are at odds with reality and legally ought to be
null and void.

AHS

 

[Arved Sandstrom]

It had better become correct, if we don't want to trash all our economies
again.

If you have liabilities to people who grabbed free stuff off the internet
labeled as providing no warranty, no one can afford to give anything away,
and it turns out that there's a huge economic efficiency boost to allowing
people to give away software. Solution: Let people give away software
with no liability or warranty.

-s

I don't think we know anything of the sort. If software is needed it
gets written, free or with a price tag. And you can't ignore the huge
economic inefficiencies occasioned by having copious amounts of turgid
broken crap available for free, that wastes everyone's time.

I think you'd find that if there was much less free stuff available that
we'd have a _different_ economic model, not necessarily a _worse_ one.

I look at warranties differently than you do. To me a warranty means
that I used proper development practices, I can make informed statements
that the published software is actually fit for a stated use, and that I
care enough about the program to offer some support.

I have no idea why you think that warranties and liabilities are going
to lead to the financial ruination of countless developers. People in
other sectors sell millions or tens of millions of other imperfect
things, with warranties, and they seem to be making a living.

AHS

 

[Brian]

Common sense has the interesting attribute that it is frequently totally
wrong.

I have published a fair amount of code which I was quite sure had at
least some bugs, but which I believed worked well enough for recreational
use or to entertain.  Or which I thought might be interesting to someone
with the time or resources to make it work.  Or which I believed worked in
the specific cases I'd had time to test.

It sounds like you're saying what I said, which is that publication for
an announced purpose - recreational use, proper operation in specific
defined cases, as a baseline for future work - is a statement that it is
fit for that purpose. If there are no qualifying statements (bug list,
READMEs etc), then the implication is that the exposed functionality of
the program is considered to work.

Either that or the author is so apathetic about his product that he
doesn't know about half the defects and can't be bothered to tell anyone
about the other half that he does know about.

I do believe that software will not cause harm *unless people do something
stupid with it*.  Such as relying on it without validating it.

Validating it? That's all well and good if you're writing a program for
other developers. It is not something that you can expect average
computer users to understand or be capable of doing.

I don't agree.  I think it is a reasonable *assumption*, in the lack of
evidence to the contrary, that the publication is a statement of *suspected*
fitness for use.  But if someone disclaims that, well, you should assume that
they have a reason to do so.

Such as, say, knowing damn well that it is at least somewhat buggy.

[ SNIP ]

It has something to do with the nature of the disclaimer. If someone
specifically documents that such-and-such functionality doesn't work,
that's cool. I can live with that - that's normal. I have much less
tolerance for the blanket disclaimer that essentially states that
_nothing_ works, except when it does. Since no developer would actually
publish a product where they truly believed that nothing worked, these
blanket disclaimers are at odds with reality and legally ought to be
null and void.

On the other hand you can only report that it works fine here.
I publish based on that and have some knowledge of what other
work environments are like. Therefore I believe that what
works here will often work there. However, since I have
little to no control over those other environments, it is
impossible to say for sure what will or won't work. Context/
Environment is everything and I'm not G-d. I don't bother
with those blanket disclaimers. I think it goes without
saying when something is a freebie.


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

 

[Seebs]

It sounds like you're saying what I said, which is that publication for
an announced purpose - recreational use, proper operation in specific
defined cases, as a baseline for future work - is a statement that it is
fit for that purpose. If there are no qualifying statements (bug list,
READMEs etc), then the implication is that the exposed functionality of
the program is considered to work.

Perhaps, unless there's an explicit disclaimer.

But if there is one, then I don't think it's reasonable to expect
functionality between that promised by the disclaimer.

Validating it? That's all well and good if you're writing a program for
other developers. It is not something that you can expect average
computer users to understand or be capable of doing.

Conveniently, in general, I don't write programs that are aimed at end
users. In general; there have been exceptions, of course.

-s

 

[Seebs]

I don't think we know anything of the sort. If software is needed it
gets written, free or with a price tag. And you can't ignore the huge
economic inefficiencies occasioned by having copious amounts of turgid
broken crap available for free, that wastes everyone's time.

No, but I can promise you that the inefficiencies of having hundreds
of entities having to build or maintain C compilers, or not being able
to use one without spending a lot of money, utterly dwarf any costs due
to gcc not being the best compiler in the world.

I think you'd find that if there was much less free stuff available that
we'd have a _different_ economic model, not necessarily a _worse_ one.

I would say necessarily worse. The alternative is a huge amount of duplicated
effort, which is a very slightly nicer-sounding way of saying a huge amount of
wasted effort.

I look at warranties differently than you do. To me a warranty means
that I used proper development practices, I can make informed statements
that the published software is actually fit for a stated use, and that I
care enough about the program to offer some support.
Right.

I have no idea why you think that warranties and liabilities are going
to lead to the financial ruination of countless developers. People in
other sectors sell millions or tens of millions of other imperfect
things, with warranties, and they seem to be making a living.

If I can't give code away without a warranty, I can't afford to give code
away. But code given away is a huge chunk of the underpinning of our
world now. Consider Linux, BSD, gcc, Apache, Firefox. Consider what happens
if the people giving them away completely for free are found to be liable
for problems. Suddenly, they have a non-trivial financial cost to recoup,
which scales with the number of people who get copies of their software, which
means that they can't afford to give it away.

We really do need the ability to give things away in an economically sane
fashion, and that means no costs imposed for having given something away,
and that means the ability to disclaim liability and let people use it at
their own risk. Which, it turns out, they are usually happy to do, because
the cost of developing their own is huge and the risk is small.

-s

 

[Jerry Coffin]

[ ... ]

Nobody knows how to build earthquake-immune buildings, yet
engineers give certain guarantees. When those are failed to be met,
(s)he is held liable. Maybe it's about time some "software
engineers" were held liable for their unreliable code in the same
way.

Unfortunately, I'm afraid you're mostly wrong. If a building falls
down, grounds for a lawsuit would be that the engineer(s) involved in
the design were "negligent". In this case, "negligent" is generally
defined to mean that the care with which they did this particular job
was substantially less than would be expected of most others in the
same profession.

To put it somewhat differently, to win such a case, you need to show
that (in essence) if virtually and of their direct competitors had
done the job instead, you'd have a reasonable assurance that you
would have received a result of substantially better quality.

In the case of software, showing such a thing would be next to
impossible. Software disasters of truly epic proportions are
commonplace, well known and easy to cite. Offhand, I'd be hard put to
think of even one "good practice" that's sufficiently widespread that
I could testify that it was at all surprising when it wasn't
followed!

 

[LR]

To my way of thinking there are some
implied obligations that come into effect as soon as a software program
is published, regardless of price. Despite all the "legal" disclaimers
to the effect that all the risk is assumed by the user of the free
software, the fact is that the author would not make the program
available unless he believed that it worked, and unless he believed that
it would not cause harm.

Aren't some programs released with known defects?

This is common sense.

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

I don't know if there is a legal principle attached to this concept, but
if not I figure one will get identified. Simply put, the act of
publishing _is_ a statement of fitness for use by the author, and to
attach completely contradictory legal disclaimers to the product is
somewhat absurd.

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

 

[Jerry Coffin]

[ ... ]

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.

Second, an earthquake of magnitude X is a known and measurable
quantity. "all virus attacks for 12 months" is a completely unknown
and unmeasurable quantity. Worse, it's an attack with malice
aforethought -- so in terms of buildings, what you're asking for is
more like a bunker guaranteed to withstand any weapon with which
anybody might attack it. Just for one example, that was the intent of
NORAD headquarters in Cheyenne Mountain -- but by the time it was
finished, there were already weapons capable of destroying it.

I can warrant software to withstand every currently known threat.
Physical buildings can't even withstand threats from decades ago --
and even withstanding threats from a century ago or more is generally
prohibitive. Software is well ahead of buildings in this respect.

As to not crashing for 2 years and/or limiting losses, it's a bit
like asking an auto manufacturer to warrant against a crash for 2
years, and if there is one that nobody will be more than mildly
injured.

 

[Michael Foukarakis]

oh, sorry. You were listing "software bugs that cost both money and
lives", I thought your list was a bit light (Ariane and Therac spring
to mind immediatly). I thought you might not have come across the
RISKs forum that discusses many computer related (and often software
related) bugs.

Oh, well, that seems rather obvious now. Lack of sleep ftl. I'm sure
Seebs got the point, anyways.

 

[James Kanze]

I have no problem with that. Some though believe that if you
give away a car and aren't aware of a problem with the car,
that you are still liable. I don't think I'm obligated to
have a car looked at by a mechanic before giving it away. If
it is safe to the best of my knowledge, then I should just
tell whoever wants the car about it's history and encourage
them to have the car checked out.

Yes. There are two things that could make you liable: deceit or
negligence. If you make claims you know aren't true, it's
deceit. As a private individual giving something away,
negligence (to the point of making you liable) is practically
impossible. As Jerry pointed out, even in the case of a large
company, with expertise in the field, it's very, very difficult.

IMHO, if you don't take well known and provenly effective
preventive measures, you're negligent. But Jerry is a lot
better versed in the legal issues than I am, so I'll take his
word for it that if everyone's doing it, you're off the hook.
And there are certainly enough software firms delivering junk to
count as almost everyone. (Although it probably depends on the
domain. Almost every firm delivering software to NASA is taking
adequate steps; for that matter, most of the telecoms software
I've seen was "correctly" developed as well.)

 

[James Kanze]

I don't think we know anything of the sort. If software is
needed it gets written, free or with a price tag. And you
can't ignore the huge economic inefficiencies occasioned by
having copious amounts of turgid broken crap available for
free, that wastes everyone's time.

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. 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).

I think you'd find that if there was much less free stuff
available that we'd have a _different_ economic model, not
necessarily a _worse_ one.

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 look at warranties differently than you do. To me a warranty
means that I used proper development practices, I can make
informed statements that the published software is actually
fit for a stated use, and that I care enough about the program
to offer some support.

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

I have no idea why you think that warranties and liabilities
are going to lead to the financial ruination of countless
developers. People in other sectors sell millions or tens of
millions of other imperfect things, with warranties, and they
seem to be making a living.

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.

 

[Arved Sandstrom]

[ ... ]

Nobody knows how to build earthquake-immune buildings, yet
engineers give certain guarantees. When those are failed to be met,
(s)he is held liable. Maybe it's about time some "software
engineers" were held liable for their unreliable code in the same
way.

Unfortunately, I'm afraid you're mostly wrong. If a building falls
down, grounds for a lawsuit would be that the engineer(s) involved in
the design were "negligent". In this case, "negligent" is generally
defined to mean that the care with which they did this particular job
was substantially less than would be expected of most others in the
same profession.

To put it somewhat differently, to win such a case, you need to show
that (in essence) if virtually and of their direct competitors had
done the job instead, you'd have a reasonable assurance that you
would have received a result of substantially better quality.

In the case of software, showing such a thing would be next to
impossible. Software disasters of truly epic proportions are
commonplace, well known and easy to cite. Offhand, I'd be hard put to
think of even one "good practice" that's sufficiently widespread that
I could testify that it was at all surprising when it wasn't
followed!

All of which is true, and all of which defines the problem. Acquisition
of quality software is hit and miss, and employment or contracting of
quality software developers is hit and miss. Mostly miss in both cases.

Peter Seebach has made a point that why worry about certifications and
warranties and so forth. He states that there exist individuals who
follow best practices - which is true - and that they don't need a
label. Furthermore, he's made a related statement that the widespread
availability of free software is very beneficial (it may or may not be,
IMHO), and that warranties and liability would be detrimental to this
process.

My take on it is, and I've said it before, certifications and warranties
and so forth are about lifting the bar. Without them purchasers and
employers need to spend a great deal more time and money to establish
what and who is quality, and what and who is not (because most of the
products and prospective employees are _not_ quality). Having
certifications/education/professional development/discipline etc which
are associated with a true profession helps provide an assurance that
*any* certified software developer you intend to hire is going to be
somewhat competent. And having guarantees on a program helps provide an
assurance that the program is suitable for a stated purpose.

The issue is that we are all craftsmen, and our "profession" is in a
pre-Industrial Era stage of craftsmanship. Except that we're missing
even a formal classification of craftsmen (apprentices, journeymen,
masters), so employers have to sort through the inflated self-labelling
so common in our field. Arguments are constantly made that software
development is somehow not amenable to being qualified and quantified,
that it's an art (and a craft), that it's impossible to create reliable
software, and so forth. These are precisely the kinds of arguments that
craftsmen made back in the day, and they don't hold any water.

We will eventually lift ourselves, or be lifted, into the status of a
profession. I'd rather do the lifting than be lifted.

AHS

 

[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.