From: Arved Sandstrom on
John Koy wrote:
> Arved Sandstrom wrote:
>> Malcolm McLean 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. They would be commercial suicide in any
>>> other field. That doesn't mean there is no such thing as software
>>> engineering, only that it is new and undeveloped. Boilers used to
>>> regularly explode at the beginning of the industrial revolution, now
>>> such accidents are almost unheard of.
>>
>> It's not a question of bug _free_ software. There aren't any other
>> fields I can think of where it's possible to get away with no liability
>> simply by claiming that it's impossible to achieve perfection.
>
> 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" ?
>
> We can't even guarantee that it won't crash tomorrow, why? Well, for me,
> because the underlying platform (OS/JRE/CLR/VM/etc) does not give me any
> guarantees. I cannot build any engineering product on top of that, no
> matter what process I employ.
>
> Engineering is not about "during", it's about "after": accountability,
> liability, warranties, hence insurability. And these shape how the
> process of "during" must be. Without them, it's just some monkey
> business, hence SD.
[ SNIP ]

Car and computer and TV manufacturers don't guarantee that their
products are 100% absolutely going to work either - why should we have
to? The point being that with existing and understood software
development methodologies, if those are assiduously applied then we can
safely state that for a given population of application deployments that
such and such a percentage of them will fail badly, another fraction
will encounter serious problems that require dedicated support under
warranty, another fraction will encounter minor problems, and so forth.

It's precisely this kind of statistical knowledge that lets you provide
consumers with certain protections - warranties, support offers, and so
forth. We're already doing it with major applications - we could do this
with the majority if we just bothered to write quality software in the
first place.

Seriously, though, why the insistence on perfection? We don't get
perfection from engineers (or other professionals) either, nor from
manufacturers of tangible goods and structures. Transportation
infrastructure crumbles before its time. We are resigned to consumer
goods that must be regarded as disposable (and not all are _designed_ to
be disposable). We accept that not so long after buying a new car that
we will be regularly repairing it. Sick buildings are common. Tens of
thousands of surgical mistakes are made every year just in North
America. Manufacturers of electronics and electrical equipment make a
mint off people who can't be bothered to return broken stuff, and buy
new replacements instead.

A software engineering profession would not require perfect software any
more than traditional engineers are expected to design perfect equipment
or machinery or structures. All I'm saying is that we can do
considerably better, and we can do that to the extent that we can
provide the same protection to consumers for software as we already for
cars or vacuum cleaners.

AHS
From: Arved Sandstrom on
Seebs wrote:
> On 2010-02-10, Michael Foukarakis <electricdelta(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.
>
> Why?
>
> Do you have any evidence to suggest that this kind of liability is actually
> reasonable, justified, and/or necessary?
>
>> 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.

Well, yeah, it does. Unless you believe that most software developers
and their employers are going to spend the extra time and money to do
all these things out of the goodness of their hearts. We already know
that the market will not force software quality to improve - it hasn't
happened yet.

AHS
From: Brian on
On Feb 10, 4:18 pm, James Kanze <james.ka...(a)gmail.com> wrote:
> On Feb 10, 10:03 am, 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.
>
> Basically no one knows how to build 100% bug-free anything.
> Witness Toyota.  Globally, in fact, you can probably do better
> with software than with most other things.  And I've never
> worked on a project where there have been liability exclusions
> (which probably aren't legal anyway).


Software from Ebenezer Enterprises is free. I think only
an idiot would attempt to sue us for a problem they find
in the software. I think the same things goes for Boost.
I don't think they've ever been sued for defects.


Brian Wood
http://webEbenezer.net
(651) 251-9384
From: Seebs on
On 2010-02-10, James Kanze <james.kanze(a)gmail.com> wrote:
> On Feb 10, 4: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.

>> Why?

>> Do you have any evidence to suggest that this kind of
>> liability is actually reasonable, justified, and/or necessary?

> Reasonable, justified or necessary, I don't know. But it's a
> fact of life. If you deliver software, and it fails, you're
> liable for it. Most of the time, the liability is spelled out
> in the contract, but that still doesn't exclude any legal
> guarantees the buyer may have.

Ahh, there was some context lost in quoting. I was asking why such terms
should be necessary to call something "engineering". Obviously, there
are markets and/or projects where they are a practical reality, and others
where they aren't.

Since most of my work is in the free software world, I see a whole lot of
software distributed without any kind of warranty whatsoever.

-s
--
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: Seebs on
On 2010-02-10, Arved Sandstrom <dcest61(a)hotmail.com> wrote:
> Seebs wrote:
>> 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.

> Well, yeah, it does. Unless you believe that most software developers
> and their employers are going to spend the extra time and money to do
> all these things out of the goodness of their hearts. We already know
> that the market will not force software quality to improve - it hasn't
> happened yet.

Not in general, but:
1. Some people will do these things because they believe it is important
to do their work to the best of their ability.
2. Some people with contracts and such in place will still produce shoddy
code.

In short, while there's certainly a correlation, liability and certification
are neither necessary nor sufficient to produce reliable software. Insisting
on them strikes me as missing the point; they're a proxy value at best for
the actual goal.

-s
--
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!