The Speed Imperative: Boyd's Law and the OODA Loop in Software
The foundation for stability in software development lies in the philosophy of "boring technology". However, the speed imperative is driven by "Boyd's Law of Iteration". Originally applied to military air combat analysis, this law reveals that the speed of the learning cycle is more crucial than the quality of an individual decision. By combining the stability provided by boring technology with the agility of Boyd's Law, a powerful synergy is created, resulting in sustainable and high-speed software development.
The OODA Loop: The Rhythm Advantage
The law formulated by US Air Force Colonel John Boyd emerged after analyzing aerial combat in the Korean War. Boyd noticed a paradox: although the American F-86 jet fighter was technically inferior to the Soviet MiG-15 in almost all performance indicators, such as climb rate and turn radius, F-86 pilots were defeating their adversaries at a ratio of nine to one.
Boyd's conclusion was that the determining factor for victory wasn't superiority in observing, orienting, deciding, or acting, but rather the ability to execute this cycle — called the OODA loop (Observe, Orient, Decide, Act) — faster than the opponent. The pilot who could complete their OODA cycle more agilely could interfere with the adversary's decision-making process, generating confusion and disorientation, thus gaining advantage.
The reason why the F-86 could iterate faster was surprisingly simple: its flight controls were fully hydraulic, while the MiG-15's were manual and required more physical force to operate. With each maneuver, the MiG-15 pilot became a little more fatigued, marginally slowing their OODA cycle. Throughout an aerial combat, this small friction disadvantage accumulated, allowing the less fatigued F-86 pilot to dictate the pace of the confrontation. This analogy is deeply relevant to software development: friction, whether cognitive or procedural, is an obstacle to speed.
Boyd's Law in Software Development
In software development, the speed of iteration is more crucial than the individual quality of each iteration. The ability to test hypotheses, get feedback, learn, and adapt quickly is more valuable than seeking the perfect solution from the start. As demonstrated by Jeff Atwood, the OODA cycle (Observe, Orient, Decide, Act) is applied to modern development practices, all focused on accelerating the feedback cycle:
- Fast Unit Tests: Tests should be concise and executed in seconds. Time- consuming tests lead developers to run them less frequently, delaying feedback on code quality.
- Agile Usability Testing: Making small changes and regular tests with users allows teams to quickly identify what doesn't work, avoiding prolonged investment in wrong directions.
- Agile Methodologies: Most agile approaches suggest iterations (sprints) of at most four weeks. This ensures continuous delivery of value and reorientation based on received feedback.
- Fail Early, Fail Often: The purpose of software testing is not to prove its functionality, but rather to identify failures as early as possible in the development cycle, when they are cheaper to fix.
In all these scenarios, the underlying principle is the same: shortening the OODA cycle. The goal is to increase the number of iterations in a given period, thus accelerating organizational learning and adaptation.
Stability and Speed: A Symbiotic Relationship
The philosophy of "choosing boring technology" and Boyd's "law of iteration", although distinct, are interdependent and mutually reinforcing. The stability and predictability of "boring" technologies are crucial for accelerating a development team's OODA cycle, minimizing friction.
The F-86 analogy illustrates this: its advantage didn't come from revolutionary technology, but from one that reduced pilot fatigue, i.e., friction. In software development, new and unproven technologies generate friction and cognitive fatigue. Engineers waste unnecessary time and energy dealing with unfamiliar stacks. "Productive Ignorance" — admitting to not knowing a new tool and preferring one already mastered — reduces this friction, allowing the team to iterate more quickly in solving real problems.
In an unfamiliar stack, the OODA cycle (Observe, Orient, Decide, Act) is negatively impacted:
- Observe: Difficulty in identifying the cause of a bug or which metrics to monitor.
- Orient: Challenges in understanding the context of a complex and unknown system, making it difficult to reason about causes and effects.
- Decide: Planning a fix becomes risky due to uncertainty about implications, leading to analysis paralysis or overly cautious solutions.
- Act: The implementation of the fix is slow and error-prone, with prolonged debugging cycles due to unexpected failures.
On the other hand, a "boring" and well-understood technology stack minimizes friction at all stages of the OODA cycle. The team knows where to look for bugs (Observe), understands the system and its interdependencies (Orient), can confidently predict the impact of changes (Decide), and implement fixes quickly and safely (Act).
By reducing operational and cognitive overhead, boring technology acts like the F-86's hydraulic flight controls. It frees the team's energy to focus on efficient execution of work, rather than fighting against their own tools. Stability does not oppose speed; it is the foundation upon which sustainable speed is built.
In the next article, we will explore how to implement faster OODA loops through specific development practices, demonstrating how to accelerate iterations without compromising system stability.