Decompression Software reliability – how to assess?

[Patoux01]

maybe a more familiar analogy would help: would you expect the carpenter or plumber building your house to also be a structural engineer? Your car mechanic to also be an advanced combustion chamber engineer?

I do expect my carpenter to have enough knowledge (through studies, or experience) to have a critical view of what the engineer asked, yes.
In the same way I expect the technicians working "under" me to have enough knowledge of milling/lathing etc so they can see if something does not seem to match and ask for confirmation. This allows to save time for both them and me, money for everyone, and potentially a much larger **** up.

"Code monkeys" is probably one of the worst things we see.

 

[Trace Malinowski]

What Andy said.

I cautiously began pushing the depth and deco time envelopes further and further for USN tables, ratio deco, VPM, and finally a Shearwater using VPM. Experience made me comfortable with each evolution. Rather than tweak conservatively, I discovered that I could deco more aggressively. I always assumed I'd be a deco weenie, but that hasn't been the case. But, as I get older, I trust that someone's math may not solve the problems of an aging physiology.

 

[KenGordon]

I prefer that any software based product I purchase is designed by a highly skilled SME and then fabricated by a highly skilled software tradesmen. Not the other way round.

Software is not at all like those industries. It is all design, all be it at different scopes. The bit which is analogous to a construction site worked was the first thing to be automated.

 

[atdotde]

What Andy said.

I cautiously began pushing the depth and deco time envelopes further and further for USN tables, ratio deco, VPM, and finally a Shearwater using VPM. Experience made me comfortable with each evolution.

While I like that approach in general, just be aware that there is a certain risk of anecdotal evidence: In my understanding, commonly accepted risk levels in scuba diving are of the order of 1 accident per several thousand dives. Very very few individual divers do enough dives (which would have to be at the edge of what is just allowed rather than deep in the comfort zone) in their whole diving life to actually probe such risk levels. I.e. if you followed exactly the same procedures for one thousand dives without getting bent that would not be enough evidence to support the claim that these practises are safe (at a commonly accepted risk level) even though repeating the same (or very similar) dive 1000 times might appear to be a lot of evidence.

 

[Kevrumbo]

I would really like an expert in aerodynamics to be deeply involved in writing aircraft flight control algorithms. I can't see why that is a bad thing.

I don't need an analogy. I do this for a living. If you think you can build stuff with people without an understanding of the problem being solved you will take a lot longer and get a worse result.

Often companies have tails to tell of grandeoise plans poorly communicated leading to failure.

The smart people running projects understand that they want the really smart people doing the actual work. The people who think they are smart and will get a bunch of unknowing minions to do the work better be good at coming up with excuses for why they need yet bigger teams and more resources. Often of course that is the actual game.

My analogy was an attempt to highlight that the software industry is still mostly a cottage industry, using trial and error methods. Hence lots of failures.

Mature industries like constructing buildings or cars have evolved to the point where design and fabrication are very separate activities. The fabrication portion is carried out by tradesmen using well defined materials and (hopefully) following industry accepted well defined procedures. The trademen know "how", not "why". They follow building codes and their work gets inspected (at least in Canada they do...).

The software industry has not yet reached this level of maturity. Design and fabrication often gets smushed together in a big mess.

I prefer that any software based product I purchase is designed by a highly skilled SME ["subject matter expert"] and then fabricated by a highly skilled software tradesmen. Not the other way round.

Software is not at all like those industries. It is all design, all be it at different scopes. The bit which is analogous to a construction site worked was the first thing to be automated.

And this is the result when you combine mature stealth aero manufacturing technology with 24 million lines of software code which turn it into a flying computer: Is the F-35 worth it?
--------------

What Andy said.

I cautiously began pushing the depth and deco time envelopes further and further for USN tables, ratio deco, VPM, and finally a Shearwater using VPM. Experience made me comfortable with each evolution. Rather than tweak conservatively, I discovered that I could deco more aggressively. I always assumed I'd be a deco weenie, but that hasn't been the case. But, as I get older, I trust that someone's math may not solve the problems of an aging physiology.

Trace, just pad & extend your O2 stop until the "niggles" go away -or just go with Buhlmann GF 40/70 or 50/80 !

 

[Trace Malinowski]

STEM cell research in scuba diving: Science, technology, engineering and math guys watch liberal arts majors like myself try it like Mikey eating Life cereal, or Pop Rocks and Coca-Cola, and adjust accordingly.

 

[joshk]

My analogy was an attempt to highlight that the software industry is still mostly a cottage industry, using trial and error methods. Hence lots of failures.

Mature industries like constructing buildings or cars have evolved to the point where design and fabrication are very separate activities.

Building software is not like building a car.

 

[KeithG]

Building software is not like building a car.

Depends upon how you look at it. Do not be confused since only 1 copy is ever assembled.

The majority of software development has matured to the point of the automobile industry in the late 1800's. Every product is a one off, finely handcrafted from scratch. Lots of trial and error and mistakes.

A very small portion of the software industry has matured to about the 1950s car makers. Extensive use of well proven standardized components assembled by trained technicians.

 

[atdotde]

What about the book writing industry? Extensive use of proven standardised words, don't you think? SCNR

 

[joshk]

The majority of software development has matured to the point of the automobile industry in the late 1800's. Every product is a one off, finely handcrafted from scratch. Lots of trial and error and mistakes.

Plenty of car accidents happen every day. Toyota recently recalled millions of vehicles. I'm not sure where you get “every product is a one off, finely handcrafted from scratch” unless you are including hobby projects in that number.

A very small portion of the software industry has matured to about the 1950s car makers. Extensive use of well proven standardized components assembled by trained technicians.

I disagree with your analogy. The “car” is a language or framework, the “application” is the usage.