Code Like a Fighter Pilot

There are some surprising similarities between developing a software product and being a fighter pilot. This article discusses some lessons software engineers can learn from the cockpit of a jet.

A Pilot Legend

The guy pictured below is John Boyd. He served as fighter jet pilot in the 50’s, then as a pilot instructor for the air force, and later in his career worked in the pentagon as an aircraft design engineer and a military strategist. John Boyd is a legend. He is widely regarded as the best fighter pilot of his time.

As an instructor for the air force, Boyd became known as “40 second Boyd”. He was given this title because of a standing bet he maintained for any pilot who challenged him: starting from a position of disadvantage, he could beat any pilot in a dogfight in under 40 seconds. He never lost even once in all of his years as an instructor.

When he worked in the pentagon, he developed his learnings as a pilot into a model for thinking about combat in general. He called it the OODA loop. At a high-level, this model emphasizes the need for speed and agility in rapidly changing environments to ensure survival.

What is another rapidly changing environment where speed and agility are key to survival? Software development. So how does Boyd’s OODA loop model apply to our jobs developing software?

The OODA Loop

O-O-D-A stands for Observe - Orient - Decide - Act. Boyd asserts that in order to survive in a changing environment, any organism or organization must execute this loop continually. The faster it can execute the loop, the higher its chances of survival. Boyd was a fighter pilot and I think you’d be hard pressed to find any other field where the environment changes faster and the stakes are higher.

In a dogfight, a pilot is moving at hundreds of miles per hour in 3D space. The pilot first observes, “where is my opponent, what is his position and velocity? What kind of aircraft is my opponent flying? What is the weather like?” and so on. The pilot then orients by interpreting the data, “what maneuvers are available to me right now? What does my opponent think I’m going to do next? What are the current set of threats?” Once oriented, the pilot decides, “I will perform the following maneuver in order to take my opponent by surprise,” and finally the pilot acts on the decision. As soon as the loop completes, the pilot starts the next iteration by observing the new state of the environment.

Boyd was successful as a pilot because he executed this loop faster than his opponents. In doing so, he disrupted his opponent’s loop by changing the environment quicker than they could cope with. The opponent’s observations were already rendered obsolete by the orient, decide, or act stages.

OODA in Software Development

At AppFolio, teams think of the sprint cycle in terms of the OODA loop. Each sprint, the team begins by observing input/feedback from the customer. As a team, they orient themselves by interpreting the data based on prior experience, biases, fears, hopes, goals, and a whole host of other factors. This most often takes the form of story grooming. Once oriented, the team decides on a course of action -- sprint planning. Finally, they act on the plan. At the end of the sprint, the team releases what they have accomplished, listens for feedback from the customer, and starts the loop again.

The faster we execute the loop, the more opportunities we have to learn, correct course, and take action. We release a new version of our software to all customers twice a week (and every day to a subset of customers). This is how we win against a changing technology landscape and our competitors. It’s how we collaborate with customers to understand what they really need. At AppFolio, agility is a primary competitive advantage.

You may be an engineer, a product manager, or a UX designer, but your real job is to give your team as many opportunities for learning and success by accelerating the loop. How can you use your particular skills and strengths to achieve this?

Accelerating the Loop

Moving fast is scary and our natural tendency when we get scared is to slow down. I recently taught my son James how to ride a bike. I ran alongside him to keep the bike stable while we got up to speed and then let go. The first few times we tried this he got scared, put on the brakes, and fell over. It was only when he started pedaling faster that he was able to maintain his balance and keep going.

Just like James, we get scared in our projects and put on the brakes. We might block a release while we wait to complete a full round of usability tests. Or we might avoid enabling the feature toggle because we are afraid of hidden corner cases we didn’t think to handle. Think creatively. Ask, “how can we speed up while dealing with our fears?” Maybe we can do something lighter weight than a full set of usability tests to answer some key questions. Or maybe we enable the feature for a subset of customers initially for a short period of time and then press ahead.

Come Fly With Us

In my experience, teams that operate this way really are like fighter pilots. They move with a heightened sense of awareness, catching and correcting issues before they become real problems. Like Boyd, these teams push the boundaries of what seems possible. Counterintuitively, they achieve greater stability and higher quality by moving faster.

I could say a lot more about the OODA loop concept and its relationship to product development -- how speed depends on mutual trust and respect, how these are built within a team, how a “gatekeeper” mindset stops the loop, or how the loop behaves at the point of diminishing returns in a project. These are topics for future posts. Until then, consider joining our team to see what it’s like first hand. We’re hiring great engineers.