Imagine you are a tactical coordinator (TACCO) on a P-8 Poseidon, the Navy’s newest antisubmarine warfare (ASW) aircraft. Your job is to maximize the tactical impact of your sensors and weapons while leading your crew. The United States is at war and you are tasked with finding and killing an adversary submarine. Intelligence indicates there is a high probability you will find your target, so you take what little time you have before the flight to make sure you’ve thought through every contingency. You know what behaviors and detection ranges other crews have observed against similar submarines, so you sketch out a few basic plans you can carry out rapidly if you have a detection opportunity. You use a few rules-of-thumb and some mental math to come up with the numbers behind your tactics. The plans are by no means optimized, but at least you have something with a chance of working.
You get to the plane, takeoff, and head toward your search area. Once you get on-station, you sample the environment and realize your plan was all wrong. The detection ranges will be far less than anticipated, and all of the tactics you planned will be laughably inadequate. You do not have the time to laboriously create new ones, though. So, you adjust your old plans to make them a little bit more conservative. It’s an art form practiced by decades of TACCOs before you. It was fine when the art hadn’t always worked in peacetime, but the stakes are much higher now.
You soon get a sniff of your target and enact your planned response to refine its exact position, course, and speed. While trying to do that, the target slips away. The rule-of-thumb plan you massaged for the dynamic environment was not up to the task. Years of training, flying, and deploying were for naught. And the adversary submarine is free to wreak havoc on U.S. forces. It did not have to be this way, though.
A New Model
The world’s best ASW aircraft should have software that helps its operators build optimized plans of action. These junior officer-led crews are trying to outthink the most cunning skippers that adversary navies can produce. Rules-of-thumb and mental math are inadequate to derive the most effective tactics possible. Thankfully, the P-8 has that software, today.
Instead of waiting for the acquisitions community to solve this problem, fleet officers and operators have filled the gap. In their free time, they have built their own software. And along with new software, they may have found a new way to build warfighting competence in the digital age.
The software in question first was conceptualized in late 2015 by a group of weapons and tactics instructors (WTIs) who wanted to plan localization tactics better. Localization is the phase of ASW where a crew tries to refine the position, course, and speed of a detected submarine. It happens to be one of the most math-heavy phases of ASW, so the team figured that an excel spreadsheet might help crews plan faster. They ended up making a spreadsheet they called iLoc. It solved localization problems in much the same way crews had been doing by hand for decades. While the tool was somewhat helpful, their largest contribution was in pointing out some of the most problematic assumptions underlying these methods. I joined the P-8 community in early 2016, took the work this group had done, and applied some software engineering concepts to build a tool that relaxed key assumptions and fully simulated localization scenarios in Javascript. The tool worked in a web browser on the aircraft, testing dozens of potential tactics to measure their effectiveness against thousands of possible submarine tracks. It could be saved on the P-8’s mission system hardware drives so that internet access wasn’t required. Soon, crews were using the tool on-station against real submarines. And that is where the real magic happened.
The initial design was clunky to use, slow, and presented information inefficiently. But as crews used the software, dubbed iLoc in honor of its predecessor, a flood of feedback arrived. With this feedback came fodder for improving the tool and extending functionality. We quickly iterated through a few dozen versions of the localization functionality in the tool, landing on a layout that allows a TACCO to go from detection opportunity to an optimal tactic in a few seconds. The tactics it recommends fail about 50 percent less often than tactics generated by TACCOs with manual methods, and it takes 95 percent less time to mission plan with iLoc than with the manual methods. It also reduced the effectiveness gap between junior and senior TACCOs by about 80 percent, massively increasing the scalability of the P-8 force.
Rapid Improvement
Over about a year and a half of hard work and endless fleet feedback, iLoc grew from 800 lines of code that helped with localization to 12,000 lines of code that suggest optimal courses of action in every mission type that the P-8 flies. The iLoc platform contains 25 distinct applications and adds a new application about once per month. One of these applications was built after it was realized that crews needed a way to tune a parameter important to a new sensor used by the P-8. Failing to get this parameter right could have wasted hundreds of thousands of dollars per flight. Implementing software native to the P-8 to tune the parameter would have taken at least a year. We implemented it into iLoc and fielded it operationally in the span of a day. Another application streamlined the intelligence reporting process, doubling the number of machine-readable reports generated on a typical P-8 mission and directly contributing to a big-data approach to naval intelligence.
Every newly introduced application is conceived, designed, built, fielded, and iteratively improved with the same process. A fleet operator comes to the iLoc Development Team, which currently consists of a few active duty P-8 officers serving in fleet squadrons, with a problem. The team sketches a rough outline of a solution with the originator of the idea and assigns the problem to a team member who builds a prototype. The team makes sure the prototype works at a basic level and fields it operationally in the next iLoc release, usually once every two weeks. Then the team puts a call out for feedback from those who have had an opportunity to test the tool and iterates the design from there. The initial fielding of applications takes about one week, on average.
This prototyping process results in quickly fielded, though minimally capable solutions to critical problems. While initially simple, applications iterate through several designs and rapidly become more useful than a contractor-built solution likely would have been. And the final applications are completed in about a month, on average. Even if assigned the highest priority, a contractor would take at least an order of magnitude longer to field similar products. Excluding the conceptual and maintenance work put into iLoc and considering only initial programming costs, it would have cost around a million dollars to procure through traditional methods. Prorating the time put in by fleet operators against their salaries, it “cost” the Navy only around $60,000.
Converting Human Understanding to Machine Understanding
While contractors and the traditional acquisitions process are hampered by onerous regulations, they are more hampered by a lack of familiarity with what software engineers call “business logic.” To truly be effective in building software for an industry, an engineer needs to be intimately familiar with how the industry operates. Building software to automate tax filing requires very different knowledge than building software to schedule airline operations. It often is better to have a small number of talented engineers on a team along with many people familiar with the business in question, rather than many talented engineers but few people familiar with the business. Too little expertise in the business in question yields software that is technically impressive but which often misses what the users actually need. The iLoc Development Team is clearly much more akin to the former than the latter. It consists of active-duty, unrestricted line officers whose primary job is to find and kill submarines, not build software.
This points to a much more fundamental understanding of what iLoc is. The applications therein are only rarely algorithmically cutting-edge. Rather, they are human understanding written in computer code. That understanding is augmented by computational techniques not accessible to humans, but human understanding is its foundation. iLoc is a repository for the corporate knowledge of how to solve tactical problems gained over 50 years of combined P-8 and P-3 (the predecessor to the P-8) operations. That collective wisdom is now available to every crew, on every flight.
While deeply rooted in the community’s history, this wisdom does not remain static. Returning to our initial vignette about a wartime TACCO, consider the following scenario. Imagine the week prior, a TACCO from a different squadron devised and experimented with a new tactic. This other TACCO was able to localize and deploy accurate torpedoes against his target utilizing the tactic. Under the pre-iLoc paradigm, word of this new tactic would diffuse through the force slowly. The originator would have to write a paper about it. Innovators would have to devise new ways to determine its effectiveness and teach them to aviators engaged in high-intensity operations. The larger force would need to laboriously practice the new tactic. And it’s likely that only the most forward thinking would take the time to do so, preferring instead to stick with what they know. This process prevents the force from quickly learning new tactics. Instead, the force remains static against a possibly dynamic enemy. When the margins of victory will be razor thin, this is unacceptable.
With iLoc, the innovative TACCO could relate the new tactic to the iLoc Development Team. The team could add the new tactic to its decision-making software applications and push an update to the wider fleet in a day. iLoc’s analytical algorithms could verify the tactic’s effectiveness. And instead of new ideas being stifled because of difficulty in learning, they could be rapidly disseminated and easily adopted by even the slowest learner. This process is not hypothetical. It has already been used to expand the tactical toolbox of P-8s on several occasions, leading to profound increases in effectiveness.
Converting Machine Understanding to Human Understanding
Under this new paradigm, software is a critical enabler. It is nothing without the human, though. Modern warfare happens extremely fast, and machines enable rapid evaluation of a multitude of tactical options. But adversaries are constantly evolving, and there are too many factors to hope to build comprehensive decision-making software. Humans’ ability to understand deep causal relationships gives them the power to keep pace with evolving enemies and to find simplicity in complexity.
While humans are intuitive and adaptable, computers are ideal for computing the likely outcomes of following human intuition. Many iLoc applications are built to do exactly this: compute the results of and optimize human-designed tactics. This means that while these applications are an extraordinary force multiplier on-station, they can be equally valuable in teaching human warfighters the fundamental nature of their profession.
iLoc allows newly minted aviators to quickly see the impact changing specific variables has on their tactics’ effectiveness. Instead of having to accumulate hundreds of hours of experience in the simulator and aircraft, a new aviator can run decision-aid software in iLoc, changing variables and instantly observing the resulting impact. In this use-case, experienced operators build applications in iLoc which then teach newer operators. iLoc makes human understanding permanent and self-reinforcing, accelerating initial training and sustaining force-wide learning.
Spreading the Model
While iLoc will continue to make the P-8 community a stronger force, that community is a small part of the Navy. We need to find ways to spread the model across the fleet to maximize its benefits. The Air Force also is experimenting with different ways of building software to aid their warfighters. Kessel Run is an Air Force-run lab that uses the same Agile software development techniques as the iLoc Development Team. It has met a large deal of initial success and likely will serve as a potent model for Department of Defense software acquisitions reform, going forward. The Navy can copy this model, and it should. But the Navy also should look to push the envelope.
In addition to building a lab that operates independent of operational units, the Navy should take a lesson from iLoc. Instead of taking software developers out of operational units as Kessel Run does, it should keep them there. Promising tacticians should be taught how to code and empowered with easy to use software platforms like iLoc to harness their knowledge and ingenuity. Officers who contribute in this manner should be taught, encouraged, and supported by the Navy’s version of Kessel Run. This organization could help cultivate warfighter-programmers and see to the maintainability of the resulting applications. As iLoc has grown, the development team has had to shift from spending 90 percent of their time on new development and 10 percent on maintenance to about 30 percent on new development and 70 percent on maintenance. The Navy’s organization should focus on offloading that burden from operational units. Operational units, for their part, should carve time out of their peoples’ days to allow them to contribute to open-source software that makes the entire force better
The traditional acquisitions apparatus can help, too. Running platforms like iLoc in a web browser is workable, but they would be much more useful if integrated within the native mission software. Building mission software with flexibility that allows users to build secure applications within them would unleash untold innovation. The iLoc team also has started working with NAVAIR to transfer several applications into the P-8’s native software architecture. In this model, iLoc serves as a prototyping environment to help direct more robust and supported acquisitions efforts.
Ultimately, the Navy has two clear options. It can continue to rely on acquisitions processes that fail again and again. This will make it easy to operate a Navy that claims to want to maximize lethality but often prefers the status quo. And Navy’s warriors will continue to deploy with less ability to make rapid, optimal decisions than they could. Or, the Navy could unleash the creative energies of our its warfighters by empowering them with the time and tools necessary to convert their expertise and ideas into a permanent advantage. The service could provide every sailor with decision-making aids that promote mission command and make it easier to distribute lethality. And doing so will be as close to free as it gets in the Department of Defense. It seems like an easy choice to me.
