Writing Software like a Fighter Pilot
How OODA loops can focus your software work
Creating software can be a mental struggle through a foggy environment. Why doesn't this code work? Where did this bug come from? How do we triage and root cause this production issue? Will we finish this project on time? Are we even working on the right thing? Developers find themselves banging their head against a piece of code for hours, even days, draining their mental energy. If it's not communicated in a timely manner, managers have more stress and more work communicating delays up the chain of command.
Sometimes these conditions can be resolved in a single sprint, but sometimes really solving the problem will take months, even years.
How can we not only survive this process, but defeat our software project enemies?
In the foggy landscape of developing software, the mental tools and analytical models developed for fighter pilots can keep us sharp and tough in the fight against building software. Fighter pilots in aerial combat must make split second decisions that determine life or death -- whether their enemies live or their own. This might not sound similar to software development, but the decision making tools fighter pilots use can help you create software more effectively.
We can use these tools to evaluate our situation both tactically and strategically and decide the best course of action. We can apply these tools at an individual level, team level, and higher organization levels to better understand our goals and next steps, and how we fit into the bigger picture.
Background
A Maverick Air Force Colonel
One Air Force fighter pilot not only permanently changed aerial combat but also was one of the most influential tactical and strategic thinkers in the last 70 years.
“Ghengis John” John “40-second” Boyd
Colonel John "40-second" Boyd started his Air Force career near the end of the Korean War. Though he never fired his guns, he was invited to the Fighter Weapons School where he graduated at the top of his class and was asked to stay as an instructor. He received his "40-second" nickname from his standing bet to beat any opponent from a disadvantaged position in less than 40 seconds. As far as records indicate, he never lost the bet.
Before Boyd, aerial combat was a mysterious and dangerous art form. After Boyd, aerial combat became a solved equation; each maneuver has a counter maneuver, every situation has an ideal action. His analysis of aerial combat spread throughout the world and is the basis of all modern combat aircraft.
Before Boyd, fighter aircraft were designed to go high or go fast. After Boyd, they were designed to build, maintain, and change energy faster than opponents; this energy-maneuverability (E-M) theory changed how aircraft performance was analyzed, and led to the F-15, F-16, and F-18 some of the most well respected fighter aircraft of all time.
Enter OODA
Most importantly for us today, Boyd described the analytical and decision making framework known as "OODA":
Observe
Orient
Decide
Act
John Boyd’s OODA loop diagram. Source
This simple framework can be used to understand how both you and your adversaries are thinking.
For a fighter pilot, you must Observe the enemy's location, Orient yourself and your jet towards them, Decide how to engage, and Act by pulling the control stick or the trigger. Though often described as a loop, OODA is better thought of as a continuous process with all phases running in parallel constantly. Sometimes Orient takes the highest precedence, other times Decisions and Actions may be more salient.
From long ranges, you might be OODA-ing using information radioed to you or given to you before you took off, possibly getting new information every few minutes. Your Decisions and Actions are primarily basic navigation.
From an intermediate range, you might OODA with information from a radar which scans the whole sky in seconds or less. Now your Decisions are based on the movement of your enemy. Your Actions begin to counter theirs.
Finally, at close range you may have to rely on your own eyes continuously to understand where the enemy is and what they might be doing. You are Deciding which way and how hard to turn, Acting constantly to be the one to win.
An example of a “one circle” fight. In this image, the blue jet is getting “inside” the turn of the red jet. Source
If you can point the front of your plane “inside” the turn of the other jet, you’ll be able to shoot the enemy. You only need to turn slightly harder or slightly sooner. Like the curves made by the planes, your decision making processes are also intertwined. If you can get similarly “inside” your enemy’s OODA, you will disrupt them and win.
OODA operates at multiple time scales, at many levels of an organization, as a mental tool to make active decisions, and as an analytical device to understand an opponent.
From its original use for fighter pilots, the OODA idea was spread by Boyd and others. Boyd's ideas completely reformed how the Marine Corps operates. OODA concepts spread outside the military, helping lawyers understand and win litigations, helping businesses understand their markets and competitors, and even becoming a useful concept for artificial intelligence and robotics.
(As an aside, Boyd developed his OODA ideas citing the works of Gödel [incompleteness], Heisenberg [uncertainty], and Skinner amongst others, see his 1976 paper “Destruction and Creation”)
OODAs in Software
Recursive Levels of OODA
Let's begin to explore how the ideas within OODA can help create software.
We'll start by imagining a developer dealing with a nasty bug. This will be familiar for anyone who's written any amount of software. We find ourselves trying to Observe the problematic behavior and understand literally anything about it. Is this easily reproducible? Is it common or rare? Are there relevant logs or metrics to correlate with the problem? Is there an associated Task/Ticket/Story/Bug filed with more information?
In this initial stage, we're primarily cycling between Observation and Orientation, though we have been making Decisions and taking Actions without much consideration. We must Decide to spend time looking for logs or metrics. We must Decide to search our project management system for bug reports. At this low, tactical level of debugging, the OODA cycle can happen very fast. These fast cycles can be critical, particularly during production issues in 24/7, high-user environments. Like a fighter pilot, the faster you can understand your environment and act upon it, the more likely you will be to resolve the problem. This speed can be useful, but it can also be a trap.
The high pace OODA loop can be satisfying, with some immediate dopamine release from each rapid experiment in the environment. Perhaps we gather enough information to create a test to reproduce the issue, but the test doesn't behave as expected. We continue with our high pace OODA loop working on the test. More work on the test yields little change in behavior, but you keep making changes to see if you can truly reproduce the problem. Many developers may spend hours in this way, with very little change in their situation. They are not making particularly useful Observations, are not re-Orienting to their situation, and are not actually making any Decisions or taking real Actions.
Low level, conscious OODA loops can be critical to success. In the example above, perhaps our test works quickly and we resolve a production outage. Our fast, conscious decisions based on feedback from our environment have helped save our software!
Perhaps our first axiom of OODA in software: well built test suites help tighten tactical OODA loops, helping deliver features and fixes faster.
Let's take a moment a re-Orient at a higher level, and add more Observations. Is this a live production issue, or a bug filed long ago? If it's a production issue, should I make sure my work and testing is coordinated with others? If it's a filed bug, do I need to be working so furiously and fruitlessly? How much time was originally allocated to this task, and should I inform someone it's taking longer than expected? Is there someone who can help me?
As an individual, remember that OODA can operate at larger organization level, and even at multiple levels within yourself. In software development, being stuck in a low level decision making cycle seems to be the most common pattern at all levels of an organization. Let OODA be a reminder to step outside of your own level and continuously Orient to other levels to ensure you're on the right path. If you're a developer, re-Orient to your team, and to the teams you work with; try to Orient to the problem you're all trying to solve and ensure your Decisions and Actions are in alignment. If you're a manager you must re-Orient upwards, downwards, and sideways: to higher levels of the decision making, to your team's needs, and to the teams you work with.
Our second axiom, then: re-Orienting your OODA loop to different time scales and organization levels is critical to success.
Time vs. Speed
Large portions of the military have been criticized for misunderstanding Boyd's OODA as a push for pure speed, when he was actually making nuanced statements about analyzing reality continuously. If we return to the fighter pilot roots of OODA, we can understand Boyd slightly better.
As a fighter pilot engaged in aerial combat, you not only need to be behind your enemy, but also be "inside" any turns they might be making. Since the enemy plane is moving forward, you must shoot ahead of it; if you think of their turn as being a complete circle, you must get "inside" this circle to successfully "lead" the enemy plane.
Getting “inside” an enemy’s turn circle, Source
When Boyd started writing about Energy-Manueverability theory in 1976, though he was speaking extremely technically about an aircraft's ability to get inside the turning circle of another aircraft, he makes this interesting note:
“... we should operate at a faster tempo than our adversaries or inside our adversaries’ time scales.”
In this context, we can understand that we clearly do not need to turn in multiple circles before our enemy can complete a single circle. We simply need to be able to turn before our enemy, or slightly faster than our enemy.
In his statement, Boyd identifies alternatives: tempo or time scales. Our production bug example above presented a high tempo. Though this may solve our problem quickly, in the original example our high tempo led us down a path full of hours of headbanging. By understanding the higher level time scales we can make better proactive decisions in our lower level OODAs. We must step back and orient ourselves in different OODAs to make better decisions.
Do not be lulled into the “Cult of the Quick”. OODA is often presented as a need for speed. Timing may be important, but OODA is most useful when used at many time scales, not simply the smallest time scale as fast as possible. As Marine Corps Commmandant Charles Krulak once said, OODA lets us think of "time as an ally", but only if we understand that time can be both fast and slow.
Using another martial practicioner for context, Bruce Lee once said of tempo:
“That little fragment of time (one beat in a cadence) which is the most suitable to accomplish effective action is called “tempo”.”
To reiterate: speed is not always the goal.
It's tempting to think of an OODA loop much like a sprint in agile development, where keeping a high tempo can accelerate delivery. Having one, single small loop where we move through the phases quickly seems like a natural conclusion; planning, sprinting, retro... planning, sprinting, retro.... While this kind of fast iteration can work for some teams and some OODAs, most people in software have experienced some of the problems of faster iteration.
A software team with fast iteration cycles may find itself so caught up in each sprint that there's little time to see the bigger picture of the project, team, or company. Similarly, if you treat OODA loops like atoms of time which we repeat as fast as possible, then you may struggle to see some of the larger elements in the world around you. In the example above, you spent hours on useless tests without checking if this was still a good direction to work in.
However you want to fight it, there are adversaries in software that operate at a time scale that doesn't fit your loops, whether your super fast scrum iteration or your hype-fast TDD cycles. Production issues tighten time scales. Strategic initiatives operate primarily at large time scales, but never get completed unless the work is propagated down to the low level where work can get done.
As a team, "cooldown" periods can help re-Orient outside the normal cadence. In a "cooldown", developers step away from product-focused work to work on whatever they think is important. This time can help set in newly gained knowledge, fix problem areas discovered in the last sprints, create tools to streamline the team's work, and share knowledge within or across teams. Sprint periods tend to be a lot of Deciding, Acting, and some Observing while Orienting seems to be saved for the beginning and end of sprints; even then, the scope of Orienting is limited to the past sprint and the next sprint. "Cooldowns" can literally help the team re-Orient to their software, the teams around them, the company, the market, and competitors, getting them un-stuck from the low level OODA loop.
Axiom 3: Software development requires Orientation to multiple time scales; tactically to implement and solve issues, strategically to ensure your team is doing the right thing.
Decision Making
Without Decisions, OODA is a scream of "OOOOOO" echoing into the void. While Orientation may be one of the most critical components of OODA, nothing changes without a Decision.
I'm sure without much thought, you can imagine a situation where your organization was frozen, cycling back and forth between Observing and Orienting without really making a Decision; they may have continued collecting data without additional value, or continued exploring known dead ends, or just keep doing whatever anyone is already doing without making a conscious choice. You may find yourself thinking of the phrase "analysis paralysis".
Not Deciding is the default state. Decision making is a continuous process, and changing nothing is still a Decision.
One cause of a "stalled" OODA loop is the discomfort of uncertainty. When there seem to be few possible Actions with unclear outcomes and unclear probability of success, making a Decision is daunting. Taking time to understand or even quantify your uncertainties can help with your Decision process.
Going back to our "endless testing" scenario, continuously trying to create a test suite to reproduce a problem clearly has diminishing returns. In the worst case scenario, the test will never be useful and at some point we need to cut our lost testing time; we cannot Observe and Orient forever. Could we have quantified our certainty earlier? When this bug first appeared, how certain were we that we could reproduce it? As we ran the first test, how confident were we? And after the 10th test? One can take this to an extreme and use Bayesian methods to truly Orient oneself to their own knowledge.
How does our uncertainty help unstick our Decisions? Let's say we're uncertain about a particular Action; we can either allocate more time to understanding that Action, or we can allocate time to finding alternative Actions. We may ask ourselves "If this Action succeeds, how good will the outcome be?" or "How much effort would it take to be more certain about this Action?" or "How much time do I have to make the next Decision?". We may discover that given our portfolio of Action options, all of our Decisions are uncertain, and we must simply make a choice. Quantifying this uncertainty can make Decisions in situations like this more obvious.
Collaboration can also create another Decision sticking point in an OODA loop. Everyone is performing their own internal Orientation, which may be different from our own. In many environments, consensus is required for Decision making. Slight mis-alignments in Orientation can lead to large disagreements in Decisions. Like uncertainty, this lack of consensus can be used to drive the next decision. Is there an area where consensus is low, but impact could be high? Is there uncertainty that can be easily removed that may drive consensus?
When building consensus, you must be aware of how others are Oriented, share new Observations with them and help explore what's making them uncertain. This forces us to state our implicit knowledge and collaboratively explore potential courses of action. Double-cruxing is a practical technique for identifying and resolving collaborative sticking points that deserves its own post. Earnest engagement during the Orientation phase can help teams stay aligned even when Acting in a course they don't agree with; each team member has been able to share their Observations, unique Orientation, and uncertainties and is certain they've been accounted for.
Our next axiom goes a bit beyond software: You must make active Decisions. Failing to Decide leads to endless loops of Observation and Orientation. Failing to Decide is death.
Awareness: Your Own OODAs
One powerful use of OODA is simply being aware of where you are in your own OODA cycles. Maybe you're wildly and chaotically making Decisions without significant Orientation. Maybe you're stuck like above, furiously Observing and Orienting, but never really Deciding or Acting. Maybe you're OODAing very well, but are stuck at a low level and should step back and look at the bigger picture.
Our inner awareness of our OODA process can help us take active control over it. While OODA can be used as a formal procedure at a set interval, awareness that you are OODAing constantly and unintentionally is a powerful tool. If you find yourself unconscious of where you are in an OODA cycle, it's probably worth a fast, intentional OODA to be sure you're making the right Decisions.
Observe: what are you working on? How long have you been working? Are there other things going on? What time is it? Are you hungry or tired? Are your eyes straining?
Orient: Do you understand why you're working on this thing? Is this how long you intended to work on it? Have higher priority items come up? What is your team doing?
Decide: Maybe you are doing the right thing. Noticing your hunger may mean you should eat, or eye strain may indicate a screen break is needed. Maybe your priorities aren't what you thought they were and you need to change tasks.
Act: Take action on your decision. Too often we know we need to eat or rest but keep working anyway. Act based on conscious Decisions.
Our axiom for personal OODAs: Be mindful of your own OODAs. Don't get "lost in the sauce", and if you notice you are lost, take a conscious scan of your situation.
It's worth noting in this section that self mindfulness is a powerful tool, whether using OODA or not.
Awareness: the OODAs of Others
We've seen what it might look like inside our own tactical OODA loop, rapidly iterating over problem solving a bug, creating a test, and fixing it. We've also discussed how it's useful to Observe other OODA loops to re-Orient ourselves in our own loop. But what other OODA loops are there for us to consider?
The original, and perhaps most obvious applications of the OODA loop were to adversarial conditions like aerial combat, or warfare more generally. In this context, OODA isn't only about our own Actions, but the Actions of our adversary. In work environments, there aren't as many clear adversaries, but there are plenty of other people working within their own OODA loops.
In the classic aerial combat context, getting "inside" your opponents OODA loop helps you disrupt their Decision making. Perhaps you can dis-Orient them, or send false Observations, or Act at a cadence they can't keep up with, again dis-Orienting them. These disruptions help you create more opportunities to win.
In a work environment, our co-workers can occasionally be adversaries. Maybe they disagree with our preferred plan of Action, maybe they are dismissive of our options, or maybe they just don't like us. If we can understand how they are OODAing, we can disrupt their cycle for our own benefit (obviously your coworkers are not your enemies, they are your collaborators, and I assume you will work in good faith to lead your organization to good decisions, not simply to build your own clout.). If we understand their Orientation, we can understand their uncertainties and Act to reduce them. If they truly don't like us, there are possibly opportunities for us to disrupt their cadence, maybe by demonstrating how valuable our Actions could be to decision makers, maybe by providing them more Observations than they asked for.
OODA loops with an organization need alignment; in particular with collaborative decision making, ensuring everyone is Oriented with the same information is critical. When a team member disagrees, they have their own Observations and Orientation that explains their disagreement. By sharing your implicit Orientation or unstated Observations you can likely help the whole team re-Orient, or may find you need to re-Orient yourself. By being aware that others typically behave rationally in their own OODA cycles, we can give them the Observations they need to re-Orient to what we see. We can go back and forth with our own self-aware OODAing to ensure we are also aligned with the group.
Our final axiom for today: Use OODA as an analytic tool to understand others; what are they Observing, how are they Acting, what might you add to their Orientation.
Concluding Thoughts: Thinking About Thinking
OODA is one of any number of tools we can use to analyze our own thinking and the thinking of others. Thinking about thinking is a long studied profession with interesting connections to software; unfortunately few software engineers and managers are exposed to ideas broadly described as metacognition. While many people working in software constantly strive to improve their technical skills, they are less likely to actively try to improve their thinking or interpersonal skills. Hopefully this post sparks an interest in other areas of self improvement.
