F-35 Block 4 – Total Crap

As you know, the F-35 does not yet have its full combat capabilities.  Those were part of the incremental Block software upgrades and should have happened years ago.  Now, the Block 4 upgrade effort has been delayed yet again.
 

The Pentagon now anticipates the F-35’s Block 4 modernization won’t be complete until 2031 at the earliest, a five-year delay from its original timeline, even as the department rescopes the effort to include fewer capabilities than originally envisioned … [1]

Note the phrases,
 
“at the earliest”
 
“include fewer capabilities than originally envisioned”
 
You know, beyond the slightest shadow of a doubt, that the even the much delayed 2031 date will slip further still and the already downgraded capabilities of the Block 4 will be further downgraded.  Honestly, at the rate we’re going, Block 4 isn’t going to deliver much in the way of new capabilities, at all.  Many features have already been deferred to a nebulous, non-existent, unfunded, future upgrade instead of the Block 4.
 
In addition, the Block 4 program is being reorganized, yet again.  GAO reports,
 

According to program officials, the new Block 4 major subprogram will have fewer capabilities, will experience schedule delays, and will have unknown costs until the program office finishes developing its cost estimate.[1]

The cost for this pile of digital crap is stunning, even by Department of Defense standards.
 

An updated cost estimate for the Block 4 effort, which was $16.5 billion as of 2021, is expected “later in 2025,” according to the GAO.[1]

Well over $16B and counting (with at least five more years of costs still to come!) and with next to nothing to show for it.  I really don’t know how to apply any value-added analysis to that.  People should be rotting in jail for this.  Okay, I guess that was my value-added analysis.
 
On the off chance that you aren’t angry about this, yet, the following should correct that.
 

The F-35 program’s use of incentive fees has largely been ineffective at holding the contractors accountable to delivering engines and aircraft on time,” the GAO stated. “For lot 15 aircraft, where the program originally tied incentives to on-time delivery, the program gave the contractor a second chance to earn fees by redirecting those incentives to other aspects of the program when it was clear that Lockheed Martin would not deliver any aircraft on time.[1]

So, we set up a contract with incentives and then paid the manufacturer incentives even after they failed to deliver aircraft on time.  People should be rotting in jail for this.  See?  More value-added analysis.
 
This is exactly the kind of thing I had hoped that SecDef Hegseth would address but he is disappointing me.  Heads should be littering the halls of the F-35 program.  What is Hegseth doing with his time?
 
 
 
_____________________________________

 
[1]Breaking Defense, “F-35 Block 4 upgrade delayed until at least 2031: GAO”, Valerie Insinna, 3-Sep-2025,
https://breakingdefense.com/2025/09/f-35-block-4-upgrade-delayed-until-at-least-2031-gao/

Hypersonic Intercept … Well, Not Really

ComNavOps never ceases to be amazed at the deceptive spin (I’ll refrain from using the word fraud, in this case) put out by manufacturers, the Navy, and complicit ‘news’ sources.  As you know, the ability of defensive systems to intercept hypersonic attacking missiles is questionable.  Well here’s a headline from a Naval News website article that sounds like a piece of great news:
 
Aegis Combat System Demonstrates System’s Capability to Counter Hypersonic Threats[1]
 
A Burke class destroyer, USS Pinckney (DDG-91) conducted a successful intercept of a hypersonic missile.  Well, that certainly sounds like good news.  Aegis performed a successful intercept of a hypersonic missile.  Great!
 
However, as we read a bit further into the article, we note the following: 

The USS Pinckney (DDG 91) successfully completed Flight Test Other 40 (FTX-40), also known as Stellar Banshee, using Lockheed Martin’s Aegis Combat System to detect, track and perform an engagement against a live advanced hypersonic Medium Range Ballistic Missile (MRBM) target using a simulated SM-6 Block IAU.[1][emphasis added]

Wait, what now?  The intercept used a simulated SM-6 defensive missile????  So, in reality, all the destroyer’s Aegis system did was track the hypersonic target.  It didn’t engage.  No actual intercept occurred.
 
Well, that changes the tone of the article and essentially refutes the headline, doesn’t it?
 
So, what did the test actually accomplish?  I don’t know the test objectives but it certainly didn’t demonstrate a successful intercept.  At best, it demonstrated the ability to track a hypersonic target which we already knew we could do.  At worst, it was a purely theoretical, software exercise that proved nothing.
 
The main thing all of this demonstrates is the need for us to be very careful and diligent in our reading of articles.  Take nothing for granted.  Assume whatever you’re reading is deceptive and make sure you really understand what you’re reading.
 
Congratulations Lockheed and Navy.  You theoretically shot down a target drone with a theoretical missile.  Theoretically … good job.
 
Congratulations Naval News website.  You managed to parrot a Lockheed press release without adding any analysis or value whatsoever.  You’re a credit to news reporters everywhere.
 
 
 
_________________________________

 
[1]Naval News website, “Aegis Combat System Demonstrates System’s Capability to Counter Hypersonic Threats”, Carter Johnston, 25-Mar-2025, Lockheed Martin Press Release
https://www.navalnews.com/naval-news/2025/03/u-s-navy-downs-maneuvering-hypersonic-missile-in-sm-6-block-iau-test/

How the F-35 Software Should Have Been Done

As we’ve seen and discussed, software has become the major obstacle to successful programs and the F-35 is probably the poster child for this.  The F-35 logistics and maintenance program, ALIS, was supposed to have been a miraculous piece of software that would do … well … everything plus several things we haven’t even thought of yet.  As it turned out, it couldn’t run a toaster correctly and may be the biggest military software flop in history.  In addition, the vaunted Block 4 software that enables full combat capability from the aircraft is years overdue with no implementation date in sight and many of the features have been permanently deferred to a non-existent ‘future’ date or deferred to the next aircraft program.  Those features will never be part of the F-35.  Even worse, because of the hugely delayed software and the resulting concurrency, we’ve produced hundreds of orphan F-35s that are so out of date that they will never be upgraded.  They’re essentially garbage throwaways at $100M each. 
 
Could all this have been avoided?  I don’t see how.  After all, this is how aircraft development and acquisition programs go, right?  I mean, everyone knows that, right? 
 
Well, let’s now take a look at how the software should have been handled and how all of this could have been avoided.  Wait … is that really possible?  Could all of this have been avoided?  Yes, it could, quite simply, as a matter of fact, and now we’ll see how.
 
 
Requirements – To begin, the software was insanely over spec’ed.  Only a lunatic – or the US military – would have attempted to cram so many features into the software.  We’ve talked about this at length.  The software had far too many requirements that had nothing to do with combat (looking at you ALIS) and nothing to do with realistic combat (looking at remote guidance handoffs and similar technology for the sake of technology features).  The military is obsessed with technology for its own sake.  Our guiding principle should be K.I.S.S. (Keep It Simple, Stupid).  One could also refer to this as K.I.S.A. (Keep It Simple, Admiral) since ‘admiral’ is a synonym for ‘stupid’.  The two words are interchangeable. 
 
By reducing the software requirements to just direct and realistic combat features we could have cut the scope, cost, and time to produce the software in half, or whatever actual large proportion.  So, half our job is done before we even begin!
 
Think of this as the Boyd approach to software:  not a single line of code that doesn’t directly enable realistic combat.  Programmer Boyd would be proud of us!
 
Of course, even with drastically pared down requirements, some significant amount of software is still required and here’s how it should have been handled.
 
We start by recognizing three absolutely critical and obvious conditions:
 
1. Software is platform agnostic. 
 
2. Software must be its own, stand-alone program, separate from the hardware program.
 
3.  Hardware development cannot proceed until the software is finalized.
 
 
Platform Agnostic Software - This is the key to software development. We didn’t need to have an actual F-35 aircraft in order to develop the software.  The software can be developed in laboratory simulations or on surrogate aircraft if an actual aircraft is needed for some reason that I can’t fathom.  We could have loaded the software on a Piper Cub, if necessary.  This would have allowed us to completely develop the software without every spending a penny on the physical aircraft.  The physical aircraft is the last thing we need.  It’s the final piece of the puzzle not the first.  The F-35 attempted to do the reverse.  They built the aircraft first and then remembered they had to add some software.  Utterly predictably, that approach failed miserably.
 
Stand-Alone Program Management – Software comes before hardware and must be its own, stand-alone project from a program management perspective.  Software cannot be an afterthought, add-on to the hardware as it was with the F-35.  The only way to effectively manage the software and avoid having it become an afterthought is to make it its own program with its own, clearly and rigidly defined requirements, schedule, and milestones.  If the software fails to meet its milestones, you don’t screw around or extend the program;  you kill it, learn lessons, fire and court-martial the managers, and move on.  Failure, then, becomes a positive in the sense that it serves as a warning – a severe warning – to the next project and manager to maintain tight control on the project and to be realistic regarding capabilities.  No more promising the moon and delivering nothing.  Fire and court-martial a few people and the next ones fall in line.
 
Start Point - Software is the hardware enabler.  Without the software, the hardware is just a very expensive paperweight.  In other words, there is no point even buying the first hardware rivet until the software is complete.  Thus, the completion of the software is what controls and triggers the start of hardware development.  This doesn’t mean partial completion with some nebulous phased delivery in the ephemeral future;  it means just what it says:  complete.  Finished.  Nothing left to do.  The contract is fully satisfied.  ‘I’s’ are dotted and ‘T’s’ are crossed.  Last line of code is written.  Had we followed this with the F-35, we would not yet have spent a single penny on the F-35 aircraft, itself.  What a savings!  We would not now have hundreds of orphans and wasted billions of dollars and have an entire fleet of only partially combat capable aircraft.  We might have even recognized, decades ago, that the software was not viable and halted the program while we could have still easily gotten out from under it.  We could have learned lessons and moved on to a second, wiser attempt (who am I kidding?  we don’t learn lessons  …  but, I digress).
 
 
Conclusion
 
Nothing that I’ve described is anything other than common sense and none of it requires any act of Congress.  It could be implemented tomorrow by nothing more than a command from the Chief of Naval Operations or Secretary of the Navy.  Some of you will protest some aspect or another but that’s just you being trapped in your paradigm and unable to see outside it.
 
Had we done this with the F-35, do you see the very early off-ramp that would have presented itself when it quickly became obvious that the software would not, and could not, be delivered in any useful time frame?  For just a hundred million dollars or so of initial programming, it would have become clear that we did not have a viable software and the program would have terminated with the hardware portion never having begun.  How many billions of dollars would we have saved? 

F-35 Software Problems Continue

We’ve previously noted that software has become the leading cause of schedule delays and cost overruns and we cited the F-35 program’s attempt to implement the Technology Refresh (TR-3) leading to Block 4 upgrades (see, “F-35 Software Case Study” and “The Heartbreak of Software”) without which the F-35 cannot achieve full combat capability.
 
About a year ago, the Pentagon put a freeze on deliveries of new F-35s pending fixes for the TR-3 implementation.  F-35s have been piling up in warehouses awaiting a resolution of the software issues.
 
Honestly, the freeze on deliveries has been more symbolic than effective since the Pentagon has continued payments for the new aircraft with just a $7M withholding per aircraft.[1]  That means that Lockheed has still been getting around 91% of the contract price for aircraft that don’t meet spec and can’t be delivered.  That’s not a bad deal if you can get it!
 
Financial aspects aside, I’m not sure any of us fully appreciate just how badly broken the software side of things are in the F-35 program.  The Pentagon has just caved to various pressures and announced that the delivery freeze has been lifted despite the software problem remaining unresolved.  Hmm …
 

Bowing to operational demands, the Pentagon has lifted a year-long freeze on accepting new F-35 stealth fighters — even though the problem that prompted the standstill has not been fully resolved.[1]
 
Persistent problems with TR-3 prompted officials to eventually capitulate to an interim software fix …[1]

 
Read this next quote slowly and carefully and fully grasp the meaning and implications.
 

… jets will be delivered with interim software that facilitates training, but a second software drop that enables combat capabilities likely won’t be available for at least another year.[1]

That’s right.  We’re delivering training jets but not fully combat capable jets.  We’re decades into this program, have built a thousand aircraft, and still don’t have a fully combat capable aircraft.  Someone should face a firing squad for this.
 
The purpose of this post is not to simply beat on the F-35 program.  Instead, I’d like to highlight a couple of points that this development hammers home for us.
 
Software – As we’ve noted, software has become the main obstacle to successful programs.  We’ve already stated that we need to change the way we treat software and make it its own program instead of just an afterthought for the hardware.  This latest incident just hammers that point home.  Our frontline combat aircraft, the F-35, is not yet fully combat capable due to continuing software problems because the software was treated as an afterthought. 
 
For acquisition programs, our focus has to be software, software, software.
 
SOFTWARE, SOFTWARE, SOFTWARE !
 
Phased Delivery – The incompetent, lazy method of running an acquisition program is to use some sort of incomplete, so-called ‘phased’ delivery where the product is delivered incomplete, to be finished over subsequent years of development.  Of course, this never works out.  The F-35, for example, has yet to achieve full combat capability and we’ve built some thousand aircraft, none of them fully combat capable.  That’s criminal and leads to endless upgrades which add to the cost of the aircraft.  That $80M aircraft becomes a $100M+ aircraft after all the upgrades are included. 
 
Further, by all accounts, we’ve produced hundreds of F-35 orphans which, due to concurrency, will never be brought up to standard and are, essentially, throwaways.  Again, that’s criminal.  This half-assed F-35 production program just hammers home the folly of any kind of phased delivery program.
 
We have to adopt a philosophy of the product, the whole product, and nothing but the whole product or don’t bother building it.
 
Contracts – The final point that this incident hammers home is the unmitigated stupidity of a contract that does not specify and demand delivery of a fully capable product in order to get paid a single penny.  You wouldn’t make a partial payment on an incomplete automobile, would you?  So why are we paying for incomplete aircraft (or ships or anything)?  Again, we need to bring back firing squads on a regular basis.
 
 
Inescapable Conclusion
 
Our acquisition program methodologies are badly broken and our military leadership is 100% complicit to the point of dereliction of duty and criminal fraud.  We have got to start learning lessons from our endless string of failures.  Congress needs to start firing admirals.  Accountability is the only way people as stupid as our military leaders will ever learn a lesson.
 
 
 
_____________________________

 
[1]Breaking Defense, “F-35 deliveries to resume next week, despite incomplete upgrade”, Michael Marrow and Valerie Insinna, 11-Jul-2024,
https://breakingdefense.com/2024/07/f-35-deliveries-to-resume-next-week-despite-incomplete-upgrade/

MQ-25 Control

The Navy’s new, not yet active, MQ-25 unmanned tanker is a fascinating control scheme case study.  You may recall that it began life as a combat UCAV concept which then morphed into a combined strike/ISR, then a pure ISR, then a combined ISR/tanker, and, ultimately, into a pure tanker … with occasional rumors of ISR or strike capabilities still being possible with minor modifications.  That convoluted development path alone makes for a fascinating story but there’s another aspect of the MQ-25 that is equally fascinating and, as best I can tell, completely ignored and that is the control scheme required to operate the tanker and how that control scheme impacts the concept of operations (CONOPS).
 
The closest I’ve seen to a CONOPS is the vague, general requirement that the tanker should be capable of delivering 14,000 lbs of fuel at a distance of 500 miles (variously reported as 15,000 lbs at 500 nm, depending on the source).  Of course, that’s not even remotely a CONOPS;  it’s a capability and an ill-defined one at that.
 
Moving on …
 
The MQ-25 consists of two main components: the MQ-25 air vehicle and the MD-5 Ground Control Station (GCS).
 
In a bit of a first for a major program, the government is acting as the lead integrator.  I applaud that, however, there won’t be any manufacturer to blame if it does not go well!
 

The Navy’s Unmanned Carrier Aviation program office (PMA-268) is moving forward with integrating its two key elements—the MQ-25 air vehicle and the MD-5 Ground Control Station (GCS) at the program’s System Test and Integration Lab (STIL) at Patuxent River.[1]
 
PMA-268 is the lead systems integrator, working closely with its two prime industry partners, Boeing  and Lockheed Martin Skunk Works … [1]
 
“This will be the first time we are integrating an air vehicle and GCS from two different prime contractors,” said T.J. Maday, MQ-25 labs and integration manager.[1]

 
Airframe development aside, the challenge is to integrate the aircraft and the GCS with the various control ship’s sensors and software.  Many levels of integration are required – no easy task.
 
 
Control Scheme
 
There is no direct ‘pilot’ control of the MQ-25.  A ground ‘pilot’ does not fly the aircraft as is done with other UAVs.  Instead, the MQ-25 will be controlled via general commands which the aircraft’s software will attempt to implement … eventually … as the immediate situation allows.  The analogy would be someone telling you to buy milk from the grocery store but they don’t give you exact, second by second instructions.  You’re given a general command and left to figure out the details and exact timing of how to go about it yourself.
 

… the AVO [air vehicle operator] is never intended to directly input singular controls to the AV, combined with the expected signal delay, this is omitted … [2]
 
AVOs will input large scale commands such as a flight path or holding pattern, an altitude or direction change while running concurrent systems like the Stingray’s fuel pod or landing gear. “The logic within the aircraft will resolve [these] requests as compatible with its current phase of flight … [2]

 
This kind of ‘execute when you can’ control is fascinating.  Consider the simple example of a command to turn to a new heading, say, 90 degrees off.  Seems simple enough, right?  But, what if an aircraft is being currently refueled?  The UAV might be wise to delay execution of the heading change until after the current aircraft finishes tanking.  On the other hand, what if the turn command is the result of an enemy threat dead ahead?  Maybe the UAV should turn very soon and very sharply?  In fact, maybe it should terminate the refueling?  Maybe there’s another friendly aircraft that needs refueling on a fairly high priority but not an emergency?  Should the UAV continue tanking or break off and disrupt the current aircraft’s plan and timing?  What’s the current aircraft going to do with the fuel it receives?  What’s the priority?  And so on … 
 
As you see, the variations to even this ‘simple’ command are infinite.  Can we write software that can correctly assess and evaluate all the possibilities?  That strikes me as no easy task considering that, for example, we’ve been working on the ‘simple’ F-35 logistics software (ALIS) for decades and have failed miserably and the F-35 Block 4 software has been largely abandoned due to failure to complete it.
 
Alternatively, what if the UAV receives no command but there is a threat dead ahead?  Does the UAV have the sensors and software to detect and interpret a threat on its own and then make an intelligent response?  While we’d like to believe that the person controlling the tanker will be omniscient and aware of all threats and command the UAV accordingly, that’s pure fantasy in actual combat.  Some threats will be detected but others will be missed or detected too late.  What if an aircraft in distress needs fuel but can’t contact whoever the UAV controller is?  With a manned tanker they might be able to contact the tanker pilot directly and request help but you can’t talk to a UAV.
 
 
Signal Delay
 
Did you note the reference in the quote to ‘expected signal delay’?  This, too, is intriguing.  We’ve come to believe that any remote, unmanned control is instantaneous and this would appear not to be the case, at least not for the MQ-25.  I don’t know what particular component of the control scheme introduces delay or what the length of the delay is. 
 
This signal delay is similar to the widespread and misguided belief that satellites provide instantaneous detection and weapons launch control against ships.
 
Consider the example of a late detected threat described above.  The pilot of a manned aircraft can react instantly when the undetected threat eventually materializes.  A UAV, especially one with a signal delay built in, cannot react instantly.  We may lose tankers while the UAV flies blithely on, uncomprehending and uncommanded.
 
It is also unclear to me whether the expected signal delay is an inherent, unavoidable characteristic of the system components or whether it’s a conscious decision that real time control is not needed.  Fascinating, either way!
 
Regardless, the approach is a wise one, in the sense that trying to control a UAV in real time in combat is not consistently possible and it is probably counter-productive to even try.  Of course, this only works if the software can be made smart enough to resolve and manage the potentially conflicting or contradicting commands the UAV will receive.
 
It is significant that there is no official mention of MQ-25 control by other airborne assets although the Navy has expressed interest in such alternate control.  At the moment, the only control is via the GCS stations which will reside on the carriers.  However, consistent with its obsession with the ‘any platform/sensor/weapon can network with any other platform/sensor/weapon’ philosophy, it now appears that the Navy is trying to make the MQ-25 controllable by other aircraft.
 

Boeing is also working with the Navy so that an airborne platform can control the MQ-25 Stingray and not just from its aircraft carrier home. When speaking about this, Rear Admiral Telford said:  “MQ-25 needs to have the ability to talk and be managed by any airborne platform, including those of our allies and partners.”[3]

 
Communications Security
 
We noted in a previous post that the desire to control the MQ-25 from other airborne assets was rooted in a fundamentally illogical assumption about communications security (see, "MQ-25 Control Concept"). 

The value in pilots being able to task MQ-25s mid-flight lies within a core assumption the Navy — and more broadly the Pentagon — has about the future battlefield: all communications will be subject to attack. The shipboard controllers may not always have contact or permission to communicate with the MQ-25 depending on the situation. If that’s the case, then a pilot of a nearby manned aircraft may need to redirect the unmanned tanker without assistance from the ship.

Of course, this raised the question, if the shipboard controller can’t communicate with the unmanned tanker due to enemy disruption of communications, why would we think that we’ll be able to communicate with the manned aircraft to tell the pilot to redirect the unmanned one?  That’s a logical inconsistency.  Military thinking just teems with this kind of logical inconsistency.
 
 
Issues
 
Communications – Regardless of the degree of communications with the MQ-25, how secure are the communication links?  Will the regular, if not constant, communications, back and forth, betray the UAV, carrier/control asset, or both locations?  Every person I’ve talked to who knows anything about signals intercept states unequivocally that our comms are nowhere near as secure as we like to believe.
 
For that matter, what type of communication signal will the MQ-25 use?  Satellite relay?  LOS?  Omni-directional?  Multiple modes?
 
Cyber Security – Anything that can receive a signal can be cyber attacked and the MQ-25 certainly qualifies.  At a minimum, the aircraft will have sensors taking in external signals and dedicated communication and data link receivers.  We don’t want a Battlestar Galactica scenario but, as we’ve seen repeatedly, even the best protected network or computer can be hacked and on a fairly regular basis.  Hardly a month goes by that I don’t receive a letter from some company saying that my customer data has been compromised and that’s from major corporations who claim to have secure networks!  China is working every day to find and develop cyber vulnerabilities in our assets.  Can an unmanned platform function reliably in the face of cyber threats? 
 
Ground Control vs. Aircraft Control – Both approaches have pros and cons, as we’ve discussed.  One further aspect of the discussion is that if you need an aircraft to control the tanker, you’ve essentially turned the ‘one-man’ tanker operation into a multi-aircraft procedure.  Requiring two aircraft to enable one to be a tanker is horribly inefficient and, essentially, doubles the cost while requiring twice the resources.
 
CONOPS – I desperately hope the Navy has thoroughly worked through the CONOPS under realistic conditions before concluding that the MQ-25 was the best solution.  My fear (near certainty) is that they hopped on board the unmanned tanker in a technology-for-the-sake-of-technology move and that an unmanned tanker is not the best solution.
 
 
 
 
 _____________________________ 
 
Note:  Fleet service timeline has been pushed back to 2026 or later.
 
 
______________________________

 
[1]Navair website, “MQ-25 team preps for first air vehicle, control station integration test event”, 18-May-2022,
https://www.navair.navy.mil/news/MQ-25-team-preps-first-air-vehicle-control-station-integration-test-event/Wed-05182022-0715
 
[2]Forbes, “Developing The MQ-25’s Ground Control Station Means Thinking Like A Mission Commander - Not A Pilot”, Eric Tegler, 12-Jan-2021,
https://www.forbes.com/sites/erictegler/2021/01/12/developing-the-mq-25s-ground-control-station-means-thinking-like-a-mission-commandernot-a-pilot/?sh=643ac901557a
 
[3]Simple Flying website, “Pushing Boundaries: What Is The Boeing MQ-25 Stingray?”, Mark Finlay, 13-Feb-2024,
https://simpleflying.com/boeing-mq-25-stingray-guide/

Software

We’ve noted many times that software has become the major obstacle in weapon system development, driving costs up and causing schedule delays.  For example, the F-35’s ALIS (logistics and maintenance) and Block 4 (full combat capability) software packages are years overdue and much of the Block 4 capabilities have been either abandoned or put off until some nebulous future date which means it will never happen.
 
Weapon and sensor systems are being delivered only partially functional due to software development issues.  In fact, it’s gotten so bad that systems are now actually being planned to deliver with only partial functionality and missing capabilities are planned (hoped) to be delivered in increments which sounds good on paper but rarely materializes.
 
What can we do?  Without software, we’re just building obscenely expensive paperweights.
 
As with almost everything combat related, the K.I.S.S. (Keep It Simple, Stupid) principle applies.  In our arrogance and laziness, we’ve allowed software to take the place of effective recon, good planning, and good tactics by asking/expecting the software to be and do everything for us.  If the software is good enough, our utterly incompetent military leadership can keep their jobs without having to do any actual work or take any actual responsibility. 
 
We’ve crammed every function we can think of into every weapon/sensor system, blowing the K.I.S.S. principle into tiny bits.
 
What happens when a system ignores the K.I.S.S. principle?  You get runaway costs, hugely delayed schedules, unreliability, unrepairability, complexity beyond the scope of the average user, chronically degraded systems, and a failure of the user to understand the capabilities of the system.
 
So, to repeat, what can we do?
 
We need to embrace K.I.S.S. and reinsert its guiding principles back into software development.  Below are some examples:  Note that I’m not going to discuss actual coding practices and coding documentation.  Those requirements go without saying and are irrelevant to the overall thrust of the post.
 
 
Simplification – We need to abandon the do-everything mentality.  That missile doesn’t need to be able to accept mid-course guidance and certainly not from a Boy Scout in Oklahoma who was handed the control from a submarine under the polar ice pack who received it from a plane operating out of a secret base in the jungle.  That missile doesn’t need an image library.  Any hit on any enemy asset will do useful damage.  Who cares which ship and what rivet it focused on?  None of this stuff will actually be used in combat.  That ship’s navigation system just needs to be able to implement a course and speed.  All the other functions are garbage.
 
Program Management – We need to treat software as the major component that it is instead of an afterthought as if we’ll just pull some extra software off the warehouse shelf.  Software needs its own program focus.  It needs to become a milestone event equal to physical construction/development.  Failure to achieve specified goals must be a ‘stop’ sign for program development just as it [theoretically] is for physical development.  We need to insist on prototype software deliveries in order to advance a project.  Just as we build demonstrators/prototypes of new aircraft, we need the same for software.
 
 
Conclusion
 
We need to acknowledge that software is the major obstacle and start making plans that realistically factor that in.  We need to recognize that software is generally more important than hardware and make the state of the software the go/no-go determining factor for the overall project instead of hardware.  The F-35 Block and Refresh efforts are a good example.  All the hardware updates in the world mean nothing without code to run on the hardware.  The F-35 is struggling with the hardware Refresh effort but vastly more important and detrimental is that the accompanying Block 4 software is years behind schedule and many of the features have been abandoned.  So, while the hardware is an issue, it’s the software that is the major problem.

F-35 Software Case Study

We’ve come to recognize that software has become the major stumbling block in weapon systems development, even more so than construction and physical performance issues (see, “The Heartbreak of Software”).
 
As you know, the F-35 was delivered in a non-combat capable condition due to software limitations.  The full-combat capable software was planned to be delivered in Block increments as listed below.
 
Blocks 1A and 1B - initial pilot training and multi-level security
Block 2A - improved training capabilities
Block 2B – basic air-to-air combat capability;  basic air-to-ground combat capability
Block 3i – Block 2B plus new hardware to support USAF IOC
Block 3F - full flight envelope and baseline combat capabilities; began 2018 and completed 2023
Block 4 – full weapons (17 new weapons) and ESM capabilities;  pending;  requires Technology Refresh 3 (TR-3)
 
Block 4 is the full combat capability version.  See Forbes[2] for a good discussion of the Block 4 upgrade but note the 2022 time of the report.  Today, Block 4 is still pending despite many of its features having been deleted and pushed into some nebulous future date land where they will languish forever and never get implemented.  Thus, even the dumbed down version of Block 4 cannot be delivered in a timely manner, being years overdue, already, and still years in the future.
 
We now have yet another example of major software problems in the software-cursed F-35.  Technology Refresh 3 (TR-3) upgrade which is required to implement the dumbed down Block 4 and make the F-35 fully combat capable has encountered major software problems resulting in the military halting acceptance of new aircraft.
 

Since July 2023, the Pentagon has refused to accept newly built F-35s due to software woes with the TR-3 upgrade, which has slipped numerous times past its original fielding date expected for April 2023.[1]
 
Problems with an upgrade installed on some Lockheed Martin F-35 Joint Strike Fighters rolling off the production line have now disrupted plans to incorporate those upgrades on existing aircraft, and the F-35 Joint Program Office does not have a date for when those jets will get the much-anticipated retrofits.[1]
 
The F-35 program “was scheduled to begin TR-3 [Technology Refresh 3] retrofits in April 2024 with the intent to modify 149 aircraft over the subsequent 12-month period,” JPO spokesperson Russ Goemaere told Breaking Defense. But now, “[t]he Program is working closely with F-35 customers to establish a new start date for those modifications based on a number of factors including software and supply chains.[1]
 
TR-3 — which features a more powerful processor, greater memory and a panoramic cockpit display that collectively enable a suite of new capabilities known as Block 4 … [1]

TR-3 began being installed in new production aircraft with Lot 15.
 
 
The military’s solution? 

“Very capable TR-2 jets will continue to fly operational missions while awaiting the start of TR-3 retrofits.”[1]

I’m sorry but no.  F-35s with TR-2/Block 3x are not ‘very capable’.  They lack most of the weapons and sensor capability required for full combat capability.
 
To provide some perspective, the F-35 has been in production since 2008-9.  That’s 16 years and we still don’t have full combat-capable aircraft due to software delays.  Just as we’ve begun retiring LCSes without them ever having had fully functional modules installed, we may see F-35s retire without ever having been fully combat capable.
 
We have got to start recognizing that software is now the primary obstacle in weapon system development and we need to modify how we approach program management and software development.
 
 
 
_____________________________________

 
[1]Breaking Defense, “Pentagon delays F-35 retrofits amid upgrade woes”, Michael Marrow, 4-Apr-2024,
https://breakingdefense.com/2024/04/pentagon-delays-f-35-retrofits-amid-upgrade-woes/
 
[2]Forbes, “Inside Block 4—The Mostly Secret Plan For Making The F-35 Fighter Even More Lethal”, Loren Thompson, 14-Nov-2022,
https://www.forbes.com/sites/lorenthompson/2022/11/14/inside-block-4-the-mostly-secret-plan-for-making-the-f-35-fighter-even-more-lethal/?sh=3a0dc3184423

The Heartbreak of Software

It has become painfully clear in recent decades that, more and more, the major stumbling block in weapon acquisition programs is software, rather than hardware. 
 
The F-35, for example, has failed on the software side of things rather than the hardware.  The all-encompassing, mission planning, parts inventory controlling, maintenance regulating, aircraft health assessing ALIS software has been a colossal, and to date, unrecoverable, failure.  Further, the F-35 was planned to be fully combat capable only with the advent of the Block 4 software upgrade which is now hopelessly behind schedule and has had many of its planned features deleted or deferred to some undetermined future time.
 

The F-35 program, now 4 years into its Block 4 modernization efforts, continues to experience cost increases and schedule expansion. Costs continued to rise during 2021 due to crucial hardware development and testing upgrades, among other things. In 2021, the program office added 3 years to its Block 4 schedule and now expects to extend Block 4 development and delivery into fiscal year 2029 …[2]

As of 2021, the program office now plans to complete Block 4 capability deliveries 3 years later than the original schedule due to software quality issues, funding challenges, and the addition of new capabilities, among others.[2]

If/when it ever happens, Block 4 will introduce over 75 major upgrades into the fighter.
 

So, the Block 4 upgrades enabled by TR-3 are quite imposing, increasing the range and diversity of weapons that can be carried, plus the sensitivity of sensors used to detect, track and engage targets. Most of the new weapons, 17 in all, are “kinetic” weapons such as missiles, but they also include non-kinetic systems that use clever software and waveforms to jam or confuse enemy warfighting systems.
 
Block 4 also enhances networking capability with other tactical systems to enable what the military calls integrated, long-range “kill webs.”[1]

However, before these changes can be implemented, the fighter’s core processor and memory unit must be improved. This is accomplished via an upgrade called Technology Refresh 3, or TR-3. The fighter’s previous computing system, TR-2, is not adequate to support the capability upgrades included in Block 4.
 

TR-3 is being installed in all new production aircraft including the Lot 15 aircraft being delivered today, and will be retrofitted onto fighters already in the fleet back to Lot 10.[1]

This would seem to imply that all aircraft delivered prior to Lot 10 will become ‘orphans’ and relegated to non-combat duties.  Thus, we see that software issues, not hardware, are going to relegate hundreds of aircraft to non-combat status.
 
Software issues not only impose schedule or ‘orphan’ penalties but actual cost penalties, as well.
 

A recent report by the Government Accountability Office noted that the cost of Block 4 upgrades to the F-35 fleet had risen to an estimated $15 billion across over a dozen years.[1]

That’s staggering and that’s just a minor software upgrade cost;  just one block of a planned four.
 
 
Discussion
 
Much of the software delays and problems associated with weapon system acquisitions are self-inflicted in the sense that we create needlessly complex requirements.  For example, the entire faddish trend of wanting to be able to control any weapon from any platform is idiotic in the extreme.  In what real world scenario would this capability be required?  The answer is … none.  This is just the pursuit of technology for its own sake.  If there was no penalty for this it would be fine;  useless but harmless.  However, the reality is that every line of code that is added to a program takes time, costs money, increases the likelihood of unintentional interferences with other bits of code, and requires time to test and debug.  When we’re already struggling – and failing – to produce useable combat aircraft in less than two decades, needlessly complex software is the last thing we should be pursuing.

 
 
 
_______________________________

[1]Forbes website, “Inside Block 4—The Mostly Secret Plan For Making The F-35 Fighter Even More Lethal”, Loren Thompson, 14-Nov-2022,
https://www.forbes.com/sites/lorenthompson/2022/11/14/inside-block-4-the-mostly-secret-plan-for-making-the-f-35-fighter-even-more-lethal/?sh=5172e58f4423
 
[2]Government Accountability Office, “F-35 Joint Strike Fighter Cost Growth and Schedule Delays
Continue”, Apr 2022, GAO-22-105128