[Jtsummers]

That's from the time when everything was still (and everything still being planned for the replacements were also) big-bang releases. 5-10 year projects to replace the broken system that still lack the necessary capabilities. I've never worked on a Navy project, but I've seen several spectacular USAF failures of similar magnitude. The most hilarious (in an absurdist sense) was having 3 generations of a system running concurrently because none of them had all the necessary features, when I left they were working on number 4.

[Goety]

Well... What is your solution for this?

[rbanffy]

Mine would be shorter development cycles and incremental deployment of improvements as soon as basic functionality is achieved. Work in an accurate simulator with an experienced crew from day one would also help.

[Jtsummers]

Don't plan projects out 5+ years and fail to revisit the plan. That is, don't do Waterfall.

Work with the actual user/operators (this I did see a lot of, but not on new systems, only on systems in "maintenance") to get regular feedback. One of the best jobs of this I saw brought in both current and retired operators. Current ones rotated through helping evaluate the system and the requirements, retired ones were hired on to be part of test/QA.

Switch from fixed contracts to more level of effort contracts.

Generally shift towards continuous delivery where possible (with information systems much easier than with embedded systems, but doable to an extent with embedded systems).

Fix the official release test phase which is often 6-24 months at the end, most of it waiting. This is part of the program's overall process which is very Waterfall in structure for most systems. I've seen work that was completed and put on a shelf for over a year before being evaluated for flight readiness. Well, it was useless to operators by that point [0] and delayed vital feedback for the next iteration. That's partly a logistics problem, but addressable.

Fix the lack of trust the operational test teams have for development teams. There was a complete lack of trust for the teams delivering the product to be tested, but the test plans for flight testing were often so bad that they were a joke (for the particular delivered systems, not flight test plans in general). If you don't have the trust, gain the trust. Take the existing operational test plans and back port them to your own test infrastructure and test efforts. Deliver that report along with the product, eventually they may trust your test reports and can start speeding things along.

As with all software, get as much testing done as early as you can. The longer you wait, the more costly it is to address discovered issues, particularly validation issues.

Finally, get experienced software engineers into program offices. Most of the time their "software engineers" are a recent college graduate, or someone from a totally unrelated field that wrote some Matlab code once. They lack sufficient experience to properly manage or guide the management of the software portion of a project. The worst I saw with this was that system I mentioned in my previous comment, the program office lead for the software portion was a newly pinned on 1st LT history major. Zero technical experience (had been in some finance role before), they trusted the contractors too much and made decisions more on their input than anyone actually using the system.

[0] For context, this is software that spent 2-4 years being developed and then would be shelved for 1-2 years before being tested. Which meant it still had 1-2 years for fielding. So from conception to release you're talking 4-8 years. That is an awful pace.