Software's evil

On Mar 28, 4:12=A0am, Paul Black <nos...@nospam.saturnine.org.uk> wrote:

> > larwe wrote:
> > > Remember the de Havilland Comet? Remember how difficult it was to get
>
> The military variant, Nimrod, is still in use and is expected to be

There's a big difference between "Get in that plane, soldier" and
"Travel the fast and easy way - individual landings - dropped directly
on your destination or points of interest in between - no return fare
necessary".

My point was that insurance doesn't mitigate doing something truly
asinine in this risk calculation malarkey (like the Ford Pinto
business) which could make your products totally unsaleable.

On Mar 28, 2:34=A0pm, larwe wrote:
> > The military variant, Nimrod, is still in use and is expected to be
>
> There's a big difference between "Get in that plane, soldier" and
> "Travel the fast and easy way - individual landings - dropped directly
> on your destination or points of interest in between - no return fare
> necessary".
>
> My point was that insurance doesn't mitigate doing something truly
> asinine in this risk calculation malarkey (like the Ford Pinto
> business) which could make your products totally unsaleable.

You read too much into my post!

My point was to point out that the Comet (or a variant of) is still
flying.

No more point to my post than that :-)

Paul

Ed Prochak wrote:
> Lanarcam <lanarc...@yahoo.fr> wrote:
>> Ed Prochak wrote :
>
>> I tend to agree with all of that, but somehow, they managed to
>> build a "complex" rocket in 1969 which involved communications
>> among many teams and at a time when tools were scarce.
>> Applying systems building techniques would certainly help.
> 
> One thing that helped: they were dealing with the laws of physics
> which are pretty stable and well defined. (Heck in 1969 they did
> most of the calculations on slide rules!)  Today's systems have a
> big issue just dealing with the user interface. And keep in mind
> the Apollo program did not go flawlessly.
> 
> NASA got very good at software development (and systems
> development), but at a high cost.  The developers were HIGHLY
> motivated. Any mistake could kill astronauts in possibly
> spectacular ways, and did! Compare that to failure in a parking
> garage gating system.
> 
> There are things they do that should be done in our development. ...

Another is to use a sane language, such as Ada.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

Mike Warren wrote:
> Lanarcam wrote:
> 
>> It depends also on the organisation or on the culture of the
>> company.  Mine is a hardware company and everyone is involved at
>> some stage in the hardware development process, from design to
>> procurement, tests, maintenance, etc. For the software, on the
>> contrary, almost no one is involved apart from the software
>> developers. Of course it's always the software's fault when
>> something goes wrong...
> 
> I do the hardware and software and find it's always Microsoft's
> fault when something goes wrong. Even on a small uC based
> project. :D

To be accurate, it is your fault for letting any Microsoft software
get within sight of your project.  There should be nothing that you
don't have the source for, and thus the ability to correct.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

Ed Prochak wrote:

[...]

> Has your company considered review of its processes according to 
 > CMM (the Capability Maturity Model)? The scale goes from 1 to 5.

Indeed, the company were I was previously, intended to do that
before I left. I told them that we were previously at level 1
and that, thanks to their reorganisation, we were now at level 0.
They didn't believe it. One year later the company was closed.

The buzzword was "cost reduction", so everything went away,
procedures, tests, validation, etc.

> NASA was the first (and
> for a long time the only) level 5. Most companies are level 1: AD HOC.
> IOW they have no real formal development process. Some companies may
> not need a formal process. (The one man company that makes parking
> garage gating systems for example.)
> 
> So if you want to improve the development process at your company, you
> can. But note that even a CMM level 5 organization can fail under
> pressures of schedule and budget.

On Mar 28, 11:35=A0am, CBFalconer <cbfalco...@yahoo.com> wrote:

> > There are things they do that should be done in our development. ...
>
> Another is to use a sane language, such as Ada.

WOW! Now, that's something you don't hear every day.

"Lanarcam" <lanarcam1@yahoo.fr> schreef in bericht
news:47eba670$0$8361$426a74cc@news.free.fr...
> Rene wrote :
>>
>> You are right about that, though it will only be possible to get a 100%
>> garantuee if You can manage to simulate every possible state in which
>> something can be and that may be possible with some simple combinatorial
>> logic circuit but will very rapidly become impossible if Your design
>> becomes more complex. And only testing managable units is not always good
>> enough either. Suppose one of them has an error which does not show up if
>> You examine it because it only alters some bit somewhere else in memory
>> (and all "replies" You get from Your unit when testing it are what You
>> expect them to be). However, when You run the system as a whole, that bit
>> might be a part of a variable in another managable unit which turned out
>> to be OK as well when You tested it isolated. So You will have to test
>> the units separately and together and creating every possible state that
>> Your system might ever stumble upon, that is impossible.
>
> This is indeed impossible to manage unless you find a way to
> fully test "manageable units" and make sure that they are free
> of side effects. Needless to say I don't have the solution.

If anyone would have the solution, he or she would probably win the Nobel
Prize. You should think about the proportions of the things we are talking
about. Imagine You have some program that accepts a string of up to 50
characters (and these are lower case letters (26 of them), upper case
letters (26 of them) and numbers (10 of them), not to mention other possible
characters which I will forget for now. If You want to fully test that
program, You would have to offer it (26+26+10)^50=an incredibly huge number
of strings. But apart from that, You will  have to offer it strings that are
too big, to check if the program will handle those in an OK fashion.

Off course You can check the source if it somehow does input checking but to
be absolutely sure (what if the compiler has an error?) You would have to
perform that test.

It is impossible.

Yours sincerely,
Rene

Rene wrote:

[..]

>>> So You will have to test
>>> the units separately and together and creating every possible state that
>>> Your system might ever stumble upon, that is impossible.
 >
>> This is indeed impossible to manage unless you find a way to
>> fully test "manageable units" and make sure that they are free
>> of side effects. Needless to say I don't have the solution.
> 
> If anyone would have the solution, he or she would probably win the Nobel
> Prize. You should think about the proportions of the things we are talking
> about. Imagine You have some program that accepts a string of up to 50
> characters (and these are lower case letters (26 of them), upper case
> letters (26 of them) and numbers (10 of them), not to mention other possible
> characters which I will forget for now. If You want to fully test that
> program, You would have to offer it (26+26+10)^50=an incredibly huge number
> of strings. But apart from that, You will  have to offer it strings that are
> too big, to check if the program will handle those in an OK fashion.

You could check that some property is true for 'a', and
that, if it is true for x, it is also true for x+1.

But then we are talking formal methods.

> Of course You can check the source if it somehow does input checking but to
> be absolutely sure (what if the compiler has an error?) You would have to
> perform that test.
> 
> It is impossible.

Given unlimited time and budget, what is really impossible ? ;)

Lanarcam wrote:

> Given unlimited time and budget, what is really impossible ? ;)

Getting unlimited time and budget. ;-P

CBFalconer wrote:
>> Another is to use a sane language, such as Ada.

larwe wrote:
> WOW! Now, that's something you don't hear every day.

Only because too few programmers recognize the benefits of using a
type-safe language.  Ada is type-safe provided you do not use the
Unchecked_Conversion and Unchecked_Deallocation packages.

By comparison, in C and C++ it is *extremely* difficult (impossible
in the fully general case) for a compiler to ensure type safety.

While a type-safe language obviously doesn't eliminate all software
bugs, it does completely eliminate one significant class of bugs.

Back in the 1980s and 1990s, a lot of people criticized Ada for being
too big a language.  Those same people seem to love C++ now, despite
it being a bigger, more complex language than Ada 95.

Eric

    If you think C++ is not overly complicated, just what is a protected
    abstract virtual base pure virtual private destructor and when was the
    last time you needed one?
              -- Tom Cargin (C++ Journal, Fall 1990)