From: Michael Foukarakis on
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 would be commercial suicide in any
> other field.

I don't see structural engineering or computer hardware engineering
going anywhere anytime soon..

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

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.
From: Malcolm McLean on
On Feb 10, 12:29 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote:
>
> In other words, we have adequate processes available but tend not to
> adopt them. And _then_ because the products are seriously flawed we
> disclaim liability because the products are in poor shape.
>
> We need to get pushed from the outside, by purchasers of our software.
> Unfortunately that hasn't happened.
>
Software management is not so stupid. If adequate procedures were
available that could ensure bug-free software, at reasonable cost and
time, they they would have been adopted. Except in a few areas
customers would soon shy away from 'no warrantry including the implied
warrantry of suitability for any particular purpose' products.

The fact is that many many formal methods are in existence. Some of
them might work, to some extent, and in some circumstances. But none
have really proved themselves when it comes to the acid test of
developing real software for non-trivial projects.
From: John Koy on
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.

>
> It's also not entirely an issue of software "engineering" being an
> infant field. The fact is that there exist adequate processes that apply
> to every stage of the software lifecycle, and most software shops only
> pay lip service to some or all of them. Doing proper requirements
> analysis is not "undeveloped". Doing proper design is not "undeveloped".
> Doing proper implementation in your languages of choice is not
> "undeveloped". And doing proper testing and QA/GC is not "undeveloped".
>
> In other words, we have adequate processes available but tend not to
> adopt them. And _then_ because the products are seriously flawed we
> disclaim liability because the products are in poor shape. That whole
> mindset is not a problem that's going to be fixed by pushing for a
> software engineering profession, because the desire for such a
> professional status follows from a mindset that already follows the
> basic principles in the first place.
>
> We need to get pushed from the outside, by purchasers of our software.
> Unfortunately that hasn't happened.
>
> AHS

From: Wojtek on
Arved Sandstrom wrote :
> And doing proper testing and QA/GC is not "undeveloped".

This is the equivalent of building a bridge, then driving over it. If
it does not collapse, then proper engineering was used.

If it does collapses, well then we just re-build it and try again.

--
Wojtek :-)


From: MarkusSchaber on
Hi,

On 10 Feb., 12:32, John Koy <John....(a)example.com> wrote:

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

And that is the problem with the abstraction levels I mentioned. Even
the OS cannot guarantee anything because our mainstream hardware is
extremely underspecified (e. G. try to get any time guarantees for
hard disk access) and does not guarantee for anything (see the long
errata list of current CPUs, or the statistics about RAM error rates
due to cosmic rays.