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?