The Imperative of Speed: Boyd's Law and the OODA Loop in Software
If the foundation for achieving stability in software is the "boring technology" philosophy, the engine that truly makes us run is "Boyd's Law of Iteration." This law, which originated from military aerial combat analysis, shows that the speed at which we learn is much more important than the quality of an isolated decision. When we combine the safety of boring technology with the agility of Boyd's Law, we create a tremendous force. The result? Development that is fast, but doesn't break halfway through. How do we manage to balance these two things?
The OODA Loop: The Advantage of Tempo
The law created by Colonel John Boyd emerged after he analyzed the dogfights during the Korean War. He noticed a very curious paradox: the American F-86 fighter jet was technically worse than the Soviet MiG-15 in almost everything, such as climb rate or tight turns. Even so, the F-86 pilots won nine out of ten engagements.
Boyd's conclusion was that the secret to victory wasn't being the best at every step, but being able to cycle through the entire loop faster than the opponent. He called this the OODA loop: Observe, Orient, Decide, and Act. The pilot who completed this cycle with more agility managed to mess with the opponent's head, creating confusion and securing the advantage.
And do you know why the F-86 managed to be faster in these iterations? The reason was quite simple: its controls were hydraulic, while the MiG-15's were manual and required a lot of physical strength. With every maneuver, the MiG pilot got a little more tired, and his loop kept getting slower. At the end of a dogfight, this accumulated fatigue let the F-86 pilot dictate the tempo of everything. For us developing software, this analogy is perfect: any friction, whether mental or procedural, is a brake on our speed. Makes sense?
Boyd's Law in Software Development
In our day-to-day work, being fast to iterate is much more valuable than trying to make every iteration perfect. Having the chance to test an idea, listen to what the user says, learn, and quickly adjust the course is worth much more than spending months searching for the ideal solution right off the bat. As demonstrated by Jeff Atwood, the OODA loop applies perfectly to the modern practices we use to accelerate feedback:
- Fast Unit Tests: They need to run in seconds. If a test takes too long, we end up running it less often, and then the feedback on the code takes longer to arrive.
- Agile Usability Testing: Making small changes and testing them right away with the system's users helps us see what doesn't work before investing too much time down the wrong path.
- Agile Methodologies: The idea of having short sprints ensures that we consistently deliver value and can reorient ourselves based on the feedback we receive.
- Fail Fast, Fail Often: The goal of testing isn't to prove that everything is right, but to find the error as soon as possible. After all, it is much cheaper to fix something right at the beginning, isn't it?
The principle here is always the same: shorten the OODA loop. The goal is to be able to do more iterations in the same amount of time, accelerating the learning of the whole team.
Stability and Speed: A Symbiotic Relationship
Choosing boring technology and following the law of iteration might seem like different things, but they actually go hand in hand. The stability of a technology we already know is what allows us to accelerate the team's OODA loop, because it removes friction from the path.
Remember the F-86? Its advantage didn't come from out-of-this-world technology, but from something that reduced the pilot's fatigue. In software, using new and unstable tools creates friction and tires the mind. We spend an enormous amount of energy trying to understand an unfamiliar stack. When we admit that we don't know something and prefer to use what we already master—what we call "Productive Ignorance"—we remove this weight and focus on solving the customer's real problem.
In a stack we don't know, every step of the OODA loop suffers:
- Observe: It becomes difficult to find the root cause of a bug or know what to monitor.
- Orient: It is a challenge to understand the context of a complicated and new system.
- Decide: Planning an adjustment becomes a risk, and uncertainty can leave us paralyzed.
- Act: The implementation becomes slow and full of new errors.
Now, when the stack is "boring" and we master everything, the friction disappears. We know where the bug usually hides, we understand how the pieces fit together, we predict the impact of changes, and we fix everything safely and quickly.
Boring technology works like the F-86's hydraulic controls. It frees the team to focus on the work that matters instead of fighting with their own tools. Stability is not the opposite of speed; it is the solid ground where true speed is built.
In the next article, we will see how to put these fast OODA loops to work in practice, accelerating deliveries without losing our grip on the system's stability.