Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: Michael Foukarakis on 11 Feb 2010 04:58
On Feb 10, 6:54 pm, Seebs <usenet-nos...(a)seebs.net> wrote:
> On 2010-02-10, Michael Foukarakis <electricde...(a)gmail.com> wrote:
> > 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.
> Do you have any evidence to suggest that this kind of liability is actually
> reasonable, justified, and/or necessary?
I am not an expert at law, so I cannot reason about justification or
necessity. However, I do recall quite a few "mishaps" and software
bugs that cost both money and lives.
Let's see: a) Mariner I, b) 1982, an F-117 crashed, can't recall if
the pilot made it, c) the NIST has estimated that software bugs cost
the US economy $59 billion annually, d) 1997, radar software
malfunction led to a Korean jet crash and 225 deaths, e) 1995, a
flight-management system presents conflicting information to the
pilots of an American Airlines jet, who got lost, crashed into a
mountain, leading to the deaths of 159 people, f) the crash of Mars
Polar Lander, etc. Common sense tells me that certain people bear
responsibility over those accidents.
How can anybody ignore this? Do more people have to die for us to
start educating software engineers about responsibility, liability,
consequences? Right now, CS students learn that an error in their
program is easily solved by adding carefully placed printf()'s or
running inside a debugger, and that the worst consequence if the TA
discovers a bug in their project solution is maybe 1/10 lesson
I was exposed to the same mentality, but it's totally fucked up.
> > That's absolutely right. But we can't sit and wait for software
> > development to be refined on its own, we should probably do something
> > about it. Collectively or whatnot.
> I agree. I just don't think that rants about liability or certification
> are going to do anything. Neither of those has a thing to do with learning
> to write more reliable software.
So what? We already know how to write more reliable software, it's
just that we don't care.
From: Phil Carmody on 11 Feb 2010 05:05
James Kanze <james.kanze(a)gmail.com> writes:
> On Feb 10, 10:38 am, Michael Foukarakis <electricde...(a)gmail.com>
>> On Feb 10, 12:03 pm, Malcolm McLean <malcolm.mcle...(a)btinternet.com>
>> wrote:> On Feb 10, 1:02 am, John Koy <John....(a)example.com>
>> wrote:> Arved Sandstrom wrote:
>> > > As long as we disclaim all liability and give no
>> > > warranties for the solutions/products we build, SD cannot
>> > > be an engineering field and the term "software engineer"
>> > > remains as an oxymoron.
>> > Basically no-one knows how to built bug-free software, so
>> > the lability exclusions are necessary.
>> 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.
> They are. That's why independent contractors have liability
In that case they're *not* liable for their unreliable code.
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
From: Seebs on 11 Feb 2010 09:10
On 2010-02-11, Arved Sandstrom <dcest61(a)hotmail.com> wrote:
> Here's the thing: the main reason for having the codes of conduct,
> required education and certifications, professional associations,
> regulated professional development, legal guarantees and so forth, is to
> prove to the consumer (employer of software developers, purchaser of
> computer software etc) with a reasonable degree of assurance that they
> are getting a known, reliable quantity, whether that be an employee or a
> product. All that stuff is there is to help regulate the market in
> software professionals and software itself, so that the consumer is not
> flying in the dark when it comes to choosing services and products.
I don't believe that they can do this, because the key measures of quality
are sufficiently orthogonal to anything we know how to test that it simply
doesn't work out that way. I'd almost certainly fail any coherently-specified
certification, because my memory's like a sieve, so any check as to whether
I know even basic things will discover that, well, no, I don't.
It's very hard to develop a test you can administer for "knows how to look
things up" or "knows whether or not he knows something".
Furthermore, I very much dislike the notion of the software industry becoming
afflicted with the kind of thing that many engineering professions, or the
legal profession, have, where certification becomes a way for groups doing
certification to make a ton of money preventing people from doing work unless
they pay the group a ton of money.
Right now, any old person can try to put software up on the internet. I would
not want to see that change, but I do not have any confidence that a
"professional organization" would be willing or able to refrain from doing so
over time. It is the nature of such organizations (like any other human
institution) to seek ever-broader power and influence.
> Such a system also protects the true software development professionals.
Some, but it may protect other people from getting the experience they would
need to *become* true software development professionals.
Had I needed a certification to start doing stuff, I would never have made
> You're quite right in a narrow sense. If you are talking about the 10%
> of developers who try, and the 10% of software shops that get it, and
> the 10% of software that is truly quality stuff, they don't need the
> extra push or the regulations. But the other 90% do.
I think the harm they'd do in the boundary cases is pretty severe, though,
and essentially irreparable, while we've found somewhat survivable ways for
employers who care about quality to obtain it if they want it.
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Lew on 11 Feb 2010 11:17
Michael Foukarakis wrote:
> How can anybody ignore this? Do more people have to die for us to
> start educating software engineers about responsibility, liability,
> consequences? Right now, CS students learn that an error in their
> program is easily solved by adding carefully placed printf()'s or
> running inside a debugger, and that the worst consequence if the TA
> discovers a bug in their project solution is maybe 1/10 lesson
You say that like the developers were at fault. I cannot tell you how many
times I've seen management overrule developers who wanted to make things
right. It's been the overwhelming majority, though. I recall a manager in
1982 refusing to let a team fix the Y2K bug in the project. Many good
developers have grown resigned to the policies and have given up pushing for
quality. Many more use stealth quality - they simply don't tell management
they're doing things in an unauthorized way that's better than the official
process. Only rarely in the last thirty years have I encountered
management alignment with known best practices.
Nearly all projects I've worked on involved many programmers, dozens even.
Parts are written independently of each other, often over a period of years.
Often each part test perfectly in isolation and only reveal bugs emergently
under production conditions.
Many of those projects had large test teams. Products have passed all the
tests, yet still failed to meet spec in production.
Sometimes the provided test environment differed significantly from the
Before you make the developer liable, you'd better darn well be certain the
developer is actually the one at fault.
From: Andy Champ on 11 Feb 2010 14:46
> You say that like the developers were at fault. I cannot tell you how
> many times I've seen management overrule developers who wanted to make
> things right. It's been the overwhelming majority, though. I recall a
> manager in 1982 refusing to let a team fix the Y2K bug in the project.
> Many good developers have grown resigned to the policies and have given
> up pushing for quality. Many more use stealth quality - they simply
> don't tell management they're doing things in an unauthorized way that's
> better than the official process. Only rarely in the last thirty years
> have I encountered
> management alignment with known best practices.
In 1982 the manager may well have been right to stop them wasting their
time fixing a problem that wasn't going to be a problem for another 18
years or so. The software was probably out of use long before that.
Right isn't necessarily perfect, or bug free. It's kind of important to
be able to sell the thing and get the income for the next release.
The trade off of course being (1) if you do it right you won't have to
do it again and (2) if you do it really badly there will be no further
We offer no warranty on my current project. We also know that if we
screw up badly enough we'll be job hunting in six months - the trade
will go elsewhere.