been developing software for over 40 years including for Uncle Sam.
I understand the rationale for IBNS as the Navy tries to do more with less headcount.
But there is an old IT saying "Build a foolproof system and only a fool will use it"
That big red button is a nice idea but the implementation sucked as it never displayed what it just changed. If it had told them where a command had been moved to (main, backup or engine room stations) it would allow people at each station to know who had control of what. In fact those monitors should be showing where command is currently assigned as far as I am concerned. Looking at the diagrams in that article, it looks like both steering and power have displays but do not say if that is the device for that monitor (eg helm, lee helm etc), or that status is which status has control no matter what mode it is set to. And from reading the article, they do not say the system told all the other helms whenever one had taken control of steering or propulsion.
Such gaps can be caused by a developer writing code to detailed requirements, but with no understanding of the actual use. Many years ago, we had issues with integrated inventory control system release. The responsible project leader was seasoned, sharp and well educated but the users were up in arms. I suggested to the project manager he should fly up to Canada and pull stock in the stockroom for a few days to learn the business his released was focused on. The guy flipped out being asked to do such a demeaning thing what with all his degrees from renowned universities around the world in system design. I insisted he fly up. I get a call 3 days later from the guy saying he needed at least another week as he had seen he light and needed time to fix several issues. Within a month, everything was working perfectly and we successfully deployed worldwide. New systems are always based on dreams of the future and not all consequences are thought out when the specs are signed off. Having folks with "cockpit time" makes a world of difference.
I am also concerned that release management on the code did not exist and every system configuration then was different. One may fix an issue on 1 ship, but there needs to be a process to ensure the code is updated every 6 months or so to ensure they have the latest fixes.
But as wonky as that code is, I keep coming back to "why the hell did they not just shut it down when things went pear shaped?".
They had 5 minutes from 1st failure until the collision. Radio an emergency on the vhf to warn local traffic and shut it down. I have had issues with the integrated nav systems on boats and when in dangerous areas especially after sunset the first thing is stop and figure out WTF is going on as there is an issue in the system and/or user. They were hours from the end of their mission. why not stop and figure it out instead of barrelling along at 20 knots? It is like you driving with speed control on you car and all the sudden the car starts to go faster and faster. Once you hit that button to disengage along with touching the brakes and it still fails, you look for a straight away so you can shut the car down knowing the steering column could lock.