I accept that people have to make the judgement calls and sign-off, but if the maps are in fact accurate why couldn't the computer at least issue a warning / red flag or similar when there are obvious problems (requested depth within some threshold of the actual depth).
I came across a scenario editor for a land training simulator that didn't provide any way of testing intervisibility between two points. The course authors wasted vast amounts of time when assigning vehicle positions clicking around maps to see if potential targets were in fact visible to the trainees. An auto check would have allowed the course authors to use their expertise to do things that couldn't be automated, building better scenarios faster.
I'm not gonna complain about it too much, but man oh man, I think you and I could build better software than what I saw, and I don't even know you from Adam.
The Air Force has an initiative called Kessel Run [1] to embrace agile software development — that might be your best route to building better software for the DoD. I'm not sure if other branches have similar programs.
https://breakingdefense.com/2021/10/not-going-solo-air-force...
Other responses have mentioned some routes inside... but beware... make the incumbents look bad too much and you'll be bought out and shut down.
Pride takes a seriously distant back seat to maintaining the current procurement monopolies and relationships, and maximizing contract payments for the least effort.
I'll stop there before I start to incriminate myself or get on watch lists if I mention possible solutions.
So that means you'd basically have to do business development first with an organization like NUWC Newport or NUWC Keyport (the undersea warfare centers who do submarine R&D) to drum up interest so that the government can issue an actual RFP or similar, and then you could bid to work on it.
I'll be the first to admit it's super difficult but if you're interested you might also consider talking with a local NavalX Tech Bridge (see https://www.secnav.navy.mil/agility/Pages/tech_bridge.aspx)
That would require the spec to have been written to allow that kind of rejection. I strongly suspect the spec was not written that well.
HN dunked all over that agile vs. waterfall article from a few days ago, wondering whether or not waterfall wasn't just some boogeyman that a bunch of consultants had to invent to sell certificates, but I'm here to tell you waterfall is a thing and it's still alive and kicking in the Navy, even now.
He was there because they were asking for software to help them sift through the cacophony of constantly-firing alarms which were distracting all their staff playing whack-a-mole "disable" and ruining situational awareness.
I imagine it's similar here. Do you want the sub to move up automatically? To fire an alarm? To dissalow a maneuver? Absolutely not. Imagine a crew knowingly pushing their vehicle into potentially dangerous maneuvers and spending those critical moments fighting the vehicle or disabling alarms.
This is how the "stick pusher" causes crashes on airplanes.
The fault lies with whomever commanded the maneuver, not with the ship for doing a minor mutiny to prevent it.
Now, as a counterpoint, see the f-16 auto-maneuver (I think this is a representative link): https://apps.dtic.mil/sti/pdfs/ADA583778.pdf
These kind of systems typically have manual overrides. If the operator truly believes they know best (or are in an exceptional situation that the automated system cannot account for), they can override the automated system (including many, if not most, safeguards). That's design 101 when you're building critical systems.
At the moment lots of maritime crew have alarm fatigue, the system constantly warns them of danger so they learn to ignore alarms and when something super serious does happen, they can ignore it
What this makes me think of:
> Why test software? It's a culture problem, not a technical problem. Just write correct software.
As long as no one ever makes a mistake it's a totally valid approach...
And nobody announces their creds up-front, making for some lively discussions.
VMS, however, was horrible a decade ago, and I'm not surprised it's still horrible. We used paper charts rather than VMS back then because it was so horrible.