Decompression Software reliability – how to assess?

[KevinNM]

My boss is involved with the Archimedes Center for Medical Device Security and lets just say that the software maturity model isn't so mature once you get outside the actual UI.

 

[fsardone]

Hello everybody,
I will not try to summarise the posts, but the following 2 struck me particularly.

The issue is trust.

In order to trust my life to a model, I have to have
(a) faith in the model
(b) faith in the implementation
About Implementation
If we talk about implementation there are two main factors for me.
1) can I trust that the model was programmed professionally and correctly?
2) can I trust that the company takes innovation seriously?
[text omitted]

I'm reasonably certain that the programs are correctly implemented but I am also sure that the people involved have no interest in further development of those products beyond the paradigm that was popular in 2000. In fact, in recent discussions it has become clear that they not only fail to innovate but zealously resist innovation. That's a red-flag to me.
R..

Rototurner speaks about trust in the programmer. And actually this thread was initiated because I also lost trust in the developer of my deco planning software.
Is it proper to assume that a software developer that zealously resists new ideas, either because they are not understood (limit on comprehension) or because are inconvenient (hidden agenda, contrary interests) would make his product(s) unsafe?

While loss of trust is a feeling and nobody can tell me how I feel but me, from a logic stand point would you believe the programmer is less capable of implementing the model or purposely alters the model?

Once trust is lost can hardly if ever be regained, but would you believe a programmer would "sabotage" its own software to make it better (according to unrecognised or obsolete ideas)?

And, if the obsolete ideas actually do not alter the model or the implementation but only the use of it, would you believe the software to be still valid and useable?

[...]
I would not overestimate the value of open source here (and I say this as an author of open source decompression software): It's a nice idea in theory but honestly, guess how many people have actually read and understood the relevant parts of the source code in say Subsurface or OSTC? For Subsurface my guess would be about a handful. I would hope that you would at least get that level of scrutiny for the closed implementations in commercial dive computers. But hey, why don't you, the reader, look into this and start contributing? For my part, I am not a professional software developer, I only do this in my spare time. I try to follow some patters but I am sure, in the professional world, this could be done with much stricter methodology.
[...]

Now about the open source issue, while I fully agree that only an handful of people have looked into it but the fact it is actually possible would discourage strange purposeful alteration, while making the software open to a forensic analysis after an incident to see if it performed properly.

Finally certification. As it is now I believe as other have pointed out that there is no appetite to pay the financial cost of it from the user base and, therefore we go back on the trust issue.

 

[Carl_F]

I asked the same question a couple years ago and the conclusion was that there is not a suite of standard benchmarks for the different deco models that software developers use. So it is "trust me".

I don't think this is the same as the medical device industry but more akin to the nuclear industry and the codes used to run thermodynamic models to validate safety systems will mitigate an accident appropriately. Theoretical models are developed and compared to experiments (and this is the same that's currently done with deco models.) But then a series of benchmarks are developed to test the implementation of the code to ensure the code matches what the theoretical model results to an appropriate level of accuracy.

I suspect the latter is happening to a degree with deco software but it's not apparent to the user nor consistent amongst the developers.

 

[DevonDiver]

Faith is earned, on an individual basis.

If the diver is patiently and progressively expanding their dives, then they'll have every opportunity to test and adjust the algorithm/s they use.

If they start conservatively and trial their chosen model towards progressively more aggressive settings and on progressively more demanding dive parameters they'll have ample opportunity to introspect on the (sub-clinical) success of their solutions.

Faith is typically only required by divers who wish to fast-track their tech diving progression without time for personal validation incrementally and in-line with dives of more punishing consequence ...

.. . or for those few conducting dives at the very outer limits of tech diving, where the linear progression of algorithmic reliability gradually breaks down.

 

[KeithG]

This is an interesting discussion. I would like to add a thought: Why is every one caught up with wanting (wishing, hoping) the programmer to be a deco expert?

The vast majority of software is constructed by code monkeys that have no knowledge of the subject matter. The standard development process involves creating a written description of the "solution" that the programmer then simply translates into a different language (a much more rigorous programming language). The programmers rarely even get introduced to the "problem" they are trying to solve.

Programming mathematical models based upon a set of formulas is relatively simple. And deco models are just that, a mathematical model.

I would be very worried if a programmer also claimed to be a Subject Matter Expert. (While these situations do exist, they are very very rare).

I would be very hesitant to trust a programmer who was either too reluctant or too exuberant in making changes to a deco model. They may be an expert software developer, but that does not mean they know anything about the theory and science of deco models.

 

[KevinNM]

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.

This is an interesting discussion. I would like to add a thought: Why is every one caught up with wanting (wishing, hoping) the programmer to be a deco expert?

The vast majority of software is constructed by code monkeys that have no knowledge of the subject matter. The standard development process involves creating a written description of the "solution" that the programmer then simply translates into a different language (a much more rigorous programming language). The programmers rarely even get introduced to the "problem" they are trying to solve.

Programming mathematical models based upon a set of formulas is relatively simple. And deco models are just that, a mathematical model.

I would be very worried if a programmer also claimed to be a Subject Matter Expert. (While these situations do exist, they are very very rare).

I would be very hesitant to trust a programmer who was either too reluctant or too exuberant in making changes to a deco model. They may be an expert software developer, but that does not mean they know anything about the theory and science of deco models.

 

[KenGordon]

This is an interesting discussion. I would like to add a thought: Why is every one caught up with wanting (wishing, hoping) the programmer to be a deco expert?

The vast majority of software is constructed by code monkeys that have no knowledge of the subject matter. The standard development process involves creating a written description of the "solution" that the programmer then simply translates into a different language (a much more rigorous programming language). The programmers rarely even get introduced to the "problem" they are trying to solve.

Programming mathematical models based upon a set of formulas is relatively simple. And deco models are just that, a mathematical model.

I would be very worried if a programmer also claimed to be a Subject Matter Expert. (While these situations do exist, they are very very rare).

I would be very hesitant to trust a programmer who was either too reluctant or too exuberant in making changes to a deco model. They may be an expert software developer, but that does not mean they know anything about the theory and science of deco models.

This is why big software projects are usually late and of poor quality. If you think you can use such code monkeys without them understanding the context of the problem you will not succeed.

There is often a ego battle between so called subject matter experts and the people doing the implementation. Sometimes experts need to pretend things are more complicated than they are, or programmers pretend they are simpler, or both.

Deco is much simpler than most stuff people have to do to earn a living.

 

[KeithG]

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?

Not going to happen.

It is no different with software. Very smart people design the system, code monkeys manufacture it.

 

[KenGordon]

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.

 

[KeithG]

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 and then fabricated by a highly skilled software tradesmen. Not the other way round.