Decompression Software reliability – how to assess?

[KeithG]

Software applications are artisanal. Rock crawling in a Jeep is artisanal. Tires are not artisanal.

The analogy @giffenk makes breaks because software isn't repeatedly manufactured like a car. There are foundational pieces and applications created with those pieces.

I tried to highlight that we should not be misled about software development since only 1 copy is being assembled. I claim this misconception is due to the fact that it is now trivial to create a second copy of a software product. Through standardization we now have a highly automated mechanism to duplicate the end product.

Note that creating a second copy of a program has not always been trivial. Early on I worked with GEPAC computers. The company I worked for had 2 of them. BUT: They had different instruction sets due to us modifying the wire wrap backplane that controlled the instruction set for a few opcodes. moving a program from 1 machine to the other required recoding certain parts of the program.

Just because only 1 copy is made does not make it artisanal. Artisanal software is a huge red flag.

Similarly, wanting your software expert to also be a SME is a red flag.

Do you want someone who is good at software? Or some one who understands the problem and all of its solutions? Different skill sets.

 

[KevinNM]

If you don't have a physiologist involved in your patient telemetry system software design or pilots and electrical engineers involved in your flight control software development I am not going to predict success. SME are essential to ensure that the product does what the users expect and that it actually works.

They don't have to be writing it, but they need to be have a veto on design and revision.

 

[KeithG]

If you don't have a physiologist involved in your patient telemetry system software design or pilots and electrical engineers involved in your flight control software development I am not going to predict success. SME are essential to ensure that the product does what the users expect and that it actually works.

They don't have to be writing it, but they need to be have a veto on design and revision.

I agree 100%. And I want to point out (in general, once again) that your SME and your software expert are different people.

 

[rsingler]

I want to thank @The Chairman for his new Xenforo platform, in which one of the side benefits is "Similar Threads"!

I would likely NEVER have found this thread.
As most of the original participants are still around...bump!

 

[atdotde]

As this thread is reviewed, I can add one data point: I wrote large parts of the Subsurface decompression code and have been maintaining it for a number of years. I am not a professional software engineer nor computer scientist, I do this as a hobby. My training is that I have a PhD in theoretical physics (elementary particles and string theory, though) and I believe I have a good understanding in the models being used, their properties and limitations. Also I have no formal training in any medical profession. Still I would claim that the Subsurface dive planner is pretty much as good as it gets for recreation and diving (military and commercial saturation diving are a different kind of thing). And at least we try to be transparent in what we do. We have tested several dive plans against the output of several other software products without finding any big differences at least to those programs that we trust, in our build process we make sure that we don't change the deco algorithm by accident (having tests that make sure the plans look exactly what they looked like yesterday). Also I write about it in my blog (https://thetheoreticaldiver.org) when I learn something new (to me ) about decompression so people can see it and comment on it. Not having access to a chamber to do hundreds of test bending divers as some research facilities have this is the best we can do. And I should not forget to mention that others in the Subsurface development team are much more senior than when it comes to software development and they make sure high standards of code quality are maintained.

 

[Angelo Farina]

I am the auyhor of three widely employed software packages, in the field of acoustics. I am an acoustics engineer, not a computer science engineer.
My experience is that in engneering and science the best software is developed by engineers and scientists, not by professional programmers. You need a deep understanding of the physics behind the problem for writing a computer program which has to predict a complex physical phenomenon.
This results in program which have simple GUI and are not "fancy", but work reliably and accuretely.
Professional programmers should be hired just for web commerce, or other not-critical tasks were only money is involved, not human lifes.

 

[dmaziuk]

You really don't want to see code used in web commerce. Most professional programmers take one look and strongly advise their marketing departments to find an "as a service" provider for all their e-commerce needs.
It's not all the programmers' fault: your "complex physics phenomena" are nothing compared to regulatory requirements, compliance rules, and tax statutes. Laws of physics are not subject to change when the best Parliament the money can buy votes on them.