Motivation of software professionals

[MarkusSchaber]

Is it? What about the software that controls the locks, cars, and
airplanes?

As I said, only a few places. Try to find an insurance against word
corrupting your PhD Thesis, and you'll understand.

Markus

 

[Brian]

Imagine the cook at a soup kitchen storing raw and fried
chicken in the same container.

Or imagine a company giving out away a free game as a marketing
stunt and the game turns out to have been infected with a virus
that formats the users' hard-drives.

Or imagine the author of an open-source product not paying
sufficent attention and accepting a patch from a third party
which turns out to have included a backdoor, providing full
access to any system where the program is running.

You clipped what I wrote about revealing known problems.
If I give someone a twenty dollar bill and later when they
use that bill it is found to be a counterfeit, I don't think
they will sue me unless they have some reason to believe I
knew it was a counterfeit.



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

"And David longed, and said, Oh that one would give me
drink of the water of the well of Bethlehem, that is at
the gate!" 1 Chronicles 11:17

 

[Brian]

Yes, because that doesn't really matter when it comes to
legal liability.

Well, that's not entirely true -- if someone can prove that
you _did_ know about a flaw in the product, you're going to
be in hot waters. But merely showing that you were ignorant
of a flaw isn't sufficent to absolve you of liability: the
cook in the soup kitchen isn't going to _know_ that the food
he serves is contaminated with salmonella and Toyota didn't
_know_ that their accelerator pedals were faulty.

It's not whether you're aware of flaws in your work that
matters, but whether you did your job properly and with
due diligence.

That is true in a traditional model of exchanging
money for a product or service. If you don't pay
for the good or service, you have no "rights."
If someone asks me for money and I unknowingly give
them a counterfeit bill, for them to become angry
with me for that would be wrong on their part.
At that point you just stop having contact with them.


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

 

[Seebs]

That's quite simply not correct.

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

 

[James Kanze]

Lew wrote:

Pretty well everything I saw back in 1982 was out of use by
1999. How much software do you know that made the transition?

Let's see.. Operating systems. The PC world was... umm.. CP/M
80? Maybe MS-Dos 1.0? And by 1999 I was working on drivers
for Windows 2000. That's at least two, maybe three depending
how you count it, ground-up re-writes of the OS.

With that almost all the PC apps had gone from 8 bit versions
in 64kb of RAM to 16-bit DOS to Windows 3.1 16-bit with
non-preemptive multitasking and finally to a 32-bit app with
multi-threading and pre-emptive multitasking running in
hundreds of megs.

OK, so how about embedded stuff? That dot-matrix printer
became a laserjet. The terminal concentrator lost its RS232
ports, gained a proprietary LAN, then lost that and got
ethernet. And finally evaporated in a cloud of client-server
computing smoke.

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.

I'm not so up on the mainframe world - but I'll be surprised
if the change from dumb terminals to PC clients didn't have a
pretty major effect on the software down the back.

Have you been to a bank lately, and seen what the clerk uses to
ask about your account? In more than a few, what you'll see on
his PC is a 3270 emulator. Again, a technology which goes back
to the late 1960's/early 1970's.

Where do you get your conclusions that there was much software
out there that was worth re-writing eighteen years ahead of
time?

It depends on what you're writing, but planned obsolescence
isn't the rule everywhere.

 

[James Kanze]

Where Brian's example falls down is that the previous owner of
the car is, in effect, just a reseller: he isn't likely to
have manufactured the car or modified it to any degree.

However, let us assume that he _has_ done modifications to the
car such as, say, replacing the fuel tank. If he messed up the
repair and, without realising it, turned the fuel car into a
potential firebomb, he would be liable for this defect even if
he gave the car away free of charge.

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 don't think the law is immature when it comes to software.
Ultimately, software is covered by the same laws as Ford
Pintos. That said, the legal practice might be lagging behind,
as might the market and users' awareness of legal rights and
duties.

It is, because there's relatively little jurisprudence. That's
one of the things that makes liability insurance for a
contractor so expensive---the insurance company doesn't really
know how much they're risking (so they assume the worst).

 

[Brian]

That's quite simply not correct.

Who has successfully sued a Boost developer or Boost
as a whole over their open source code? No one has
sued Ebenezer Enterprises either. T


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

 

[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