OODA Loop

…copied directly from the wikipedia page…
OODA Loop

 

The OODA loop (for observe, orient, decide, and act) is a concept originally applied to the
combat operations process
, often at the strategic level in military operations. It is now also often applied to understand commercial operations and learning processes. The concept was developed by military strategist and USAF Colonel John Boyd.

Overview

The OODA loop has become an important concept in litigation,[1] business[2] and military strategy. According to Boyd, decision-making occurs in a recurring cycle of observe-orient-decide-act. An entity (whether an individual or an organization) that can process this cycle quickly, observing and reacting to unfolding events more rapidly than an opponent, can thereby “get inside” the opponent’s decision cycle and gain the advantage. Frans Osinga argues that Boyd’s own views on the OODA loop are much deeper, richer, and more comprehensive than the common interpretation of the ‘rapid OODA loop’ idea.[3]

Boyd developed the concept to explain how to direct one’s energies to defeat an adversary and survive. Boyd emphasized that “the loop” is actually a set of interacting loops that are to be kept in continuous operation during combat. He also indicated that the phase of the battle has an important bearing on the ideal allocation of one’s energies.

Boyd’s diagram shows that all decisions are based on observations of the evolving situation tempered with implicit filtering of the problem being addressed. These observations are the raw information on which decisions and actions are based. The observed information must be processed to orient it for further making a decision. In notes from his talk “Organic Design for Command and Control”, Boyd said,

The second O, orientation – as the repository of our genetic heritage, cultural tradition, and previous experiences – is the most important part of the O-O-D-A loop since it shapes the way we observe, the way we decide, the way we act.

As stated by Boyd and shown in the “Orient” box, there is much filtering of the information through our culture, genetics, ability to analyze and synthesize, and previous experience. Since the OODA Loop was designed to describe a single decision maker, the situation is usually much worse than shown as most business and technical decisions have a team of people observing and orienting, each bringing their own cultural traditions, genetics, experience and other information. It is here that decisions often get stuck, which does not lead to winning, since

In order to win, we should operate at a faster tempo or rhythm than our adversaries–or, better yet, get inside [the] adversary’s Observation-Orientation-Decision-Action time cycle or loop. … Such activity will make us appear ambiguous (unpredictable) thereby generate confusion and disorder among our adversaries–since our adversaries will be unable to generate mental images or pictures that agree with the menacing as well as faster transient rhythm or patterns they are competing against.

The OODA loop, which focuses on strategic military requirements, was adapted for business and public sector operational continuity planning. Compare it with the Plan Do Check Act (PDCA) cycle or Shewhart cycle, which focuses on the operational or tactical level of projects.

As one of Boyd’s colleagues, Harry Hillaker, put it in “John Boyd, USAF Retired, Father of the F16“:

The key is to obscure your intentions and make them unpredictable to your opponent while you simultaneously clarify his intentions. That is, operate at a faster tempo to generate rapidly changing conditions that inhibit your opponent from adapting or reacting to those changes and that suppress or destroy his awareness. Thus, a hodgepodge of confusion and disorder occur to cause him to over- or under-react to conditions or activities that appear to be uncertain, ambiguous, or incomprehensible.

The OODA Loop also serves to explain the nature of surprise and shaping operations in a way that unifies Gestalt psychologycognitive science and game theory in a comprehensive theory of strategy. Utility theory (the basis of game theory) describes how decision are made based on the perceived value of taking an action. The OODA Loop shows that prior to making a decision (the Decide phase), the person will first have to get information (Observe) and determine what it means to him and what he can do about it (Orient). In this way, the utility sought at the Decide phase can be altered by affecting the information the opponent receives and the cognitive model he applies when orienting upon it.[4]

Writer Robert Greene wrote in an article called OODA and You that

the proper mindset is to let go a little, to allow some of the chaos to become part of his mental system, and to use it to his advantage by simply creating more chaos and confusion for the opponent. He funnels the inevitable chaos of the battlefield in the direction of the enemy.

Applicability of the OODA loop

Consider a fighter pilot being scrambled to shoot down an enemy aircraft.

Before the enemy airplane is even within visual contact range, the pilot will consider any available information about the likely identity of the enemy pilot: his nationality, level of training, and cultural traditions that may come into play.

When the enemy aircraft comes into radar contact, more direct information about the speed, size, and maneuverability of the enemy plane becomes available; unfolding circumstances take priority over radio chatter. A first decision is made based on the available information so far: the pilot decides to “get into the sun” above his opponent, and acts by applying control inputs to climb. Back to observation: is the attacker reacting to the change of altitude? Then to orient: is the enemy reacting characteristically, or perhaps acting like a noncombatant? Is his plane exhibiting better-than-expected performance?

As the dogfight begins, little time is devoted to orienting unless some new information pertaining to the actual identity or intent of the attacker comes into play. Information cascades in real time, and the pilot does not have time to process it consciously; the pilot reacts as he is trained to, and conscious thought is directed to supervising the flow of action and reaction, continuously repeating the OODA cycle. Simultaneously, the opponent is going through the same cycle.

How does one interfere with an opponent’s OODA cycle? One of John Boyd’s primary insights in fighter combat was that it is vital to change speed and direction faster than the opponent. This is not necessarily a function of the plane’s ability to maneuver, rather the pilot must think and act faster than the opponent can think and act. Getting “inside” the cycle—short-circuiting the opponent’s thinking processes—produces opportunities for the opponent to react inappropriately.

Another tactical-level example can be found on the basketball court, where a player takes possession of the ball and must get past an opponent who is taller or faster. A straight dribbleor pass is unlikely to succeed. Instead the player may engage in a rapid and elaborate series of body movements designed to befuddle the opponent and deny him the ability to take advantage of his superior size or speed. At a basic level of play, this may be merely a series of fakes, with the hope that the opponent will make a mistake or an opening will occur, but practice and mental focus may allow one to accelerate tempo, get inside the opponent’s OODA loop and take control of the situation—to cause the opponent to move in a particular way, and generate an advantage rather than merely react to an accident. Taking control of the situation is key. It is not enough to speed through OODA faster — that results in flailing.

The same cycle operates over a longer timescale in a competitive business landscape, and the same logic applies. Decision makers gather information (observe), form hypotheses about customer activity and the intentions of competitors (orient), make decisions, and act on them. The cycle is repeated continuously. The aggressive and conscious application of the process gives a business advantage over a competitor who is merely reacting to conditions as they occur, or has poor awareness of the situation. Especially in business, where teams of people are working the OODA Loop, it often gets stuck at the “D” (see Ullman) and no action is taken allowing the competition to gain the upper hand or resources to be wasted.

The approach favors agility over raw power in dealing with human opponents in any endeavor. John Boyd put this ethos into practice with his work for the USAF. He was an advocate of maneuverable fighter aircraft, in contrast to the heavy, powerful jet fighters that were prevalent in the 1960s, such as the F-4 Phantom II and General Dynamics F-111. Boyd inspired the Light Weight Fighter Project that produced the successful F-16 Fighting Falcon and F/A-18 Hornet, which are still in use by the United States and several other military powers into the 21st century.

 

Special boot-up apple-key combinations in Mac OS X

Duplicate info – – Just Testing…

via Special boot-up apple-key combinations in Mac OS X.

9781118024461-cs0102.indd

The special apple keys

First a very quick introduction to the special apple keys:

Option picture of pictogram printed on apple option keys
Also known as the alt-key. It has usually also the text “alt” printed on it.
Command picture of pictogram printed on apple command keys
Also known as the apple key or “puppy-foot” or “flower”. It has usually also an apple printed on it. It is situated next to the spacebar.
Control 
Also known as ctrl or ctl key. Situated where most modern keyboards have them.
Shift picture of pictogram printed on shift keys
As other shift keys

The key combinations

These key combinations must be pressed while powering on the machine (or while pressing the power button)

 S
Command-S
Boot into single user mode (command-line)
 V
Command-V
Boot using verbose mode
Shift
Boot using safe mode (temporarily disables login items and non-essential kernel stuff)
Option
Go into openfirmware and select boot volume
  
Command-Option-Shift
Bypass internal HD
T
Go into firewire target mode
C
Boot from internal optical drive (with a CD that has a system folder)
N
Boot from network (NetBoot)
  PR
Command-Option-P-R
Reset PRAM and NVRAM
  OF
Command-Option-O-F
Go into openfirmware
X
Force Mac OS X startup (?)
   Delete
Option-Command-Shift-Delete
Bypass internal HD and search a different startup volume (such as a CD or external disk)
R
Force PowerBook to reset screen
Mouse button
Eject CD

Perhaps useful links

Code Caveats

Test-Driven Development with Inversion of Control.

Even if you aren’t testing your code, you should write testable code. IoC enables testable code. Inject test-friendly dependencies or mocks at test time, to isolate the unit-under-test.

Avoid mixing Object Creation with Application Logic

Source

Avoid Code Smells

Source

Avoid creating technical debt.

“Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. … A little debt speeds development so long as it is paid back promptly with a rewrite … Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation …” (Emphasis mine)

Source

Premature optimisation is the root of all evil

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Source

 

Unix Philosophy

“This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface”
– Doug McIlroy
A Quarter Century of Unix [Salus]. Addison-Wesley. 1994.
ISBN 0-201-54777-5.

  • Rule of Modularity: Write simple parts connected by clean interfaces.
  • Rule of Clarity: Clarity is better than cleverness.
  • Rule of Composition: Design programs to be connected to other programs.
  • Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  • Rule of Simplicity: Design for simplicity; add complexity only where you must.
  • Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  • Rule of Transparency: Design for visibility to make inspection and debugging easier.
  • Rule of Robustness: Robustness is the child of transparency and simplicity.
  • Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
  • Rule of Least Surprise: In interface design, always do the least surprising thing.
  • Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  • Rule of Repair: When you must fail, fail noisily and as soon as possible.
  • Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  • Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
  • Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  • Rule of Diversity: Distrust all claims for “one true way”.
  • Rule of Extensibility: Design for the future, because it will be here sooner than you think.

– Eric S. Raymond, “The Art of Unix Programming”

 

Quality Matters

When I hear “JUST BANG OUT CODE THAT WORKS” I think of all the apps I don’t use anymore because they gradually lost the ability to iterate.

– Avdi Grimm

Source

Don’t do hard things, do easy things.

  • Simple is better than complex.
  • Complex is better than complicated.
  • Flat is better than nested.
  • Readability counts.
  • If the implementation is hard to explain, it’s a bad idea.
  • If the implementation is easy to explain, it may be a good idea.

– The Zen of Python

Source

Shortlist cut from Jack Diederich’s “Stop Writing Classes” talk

Don’t Write Code

Don’t write code (write new code only when everything else fails) is the single most important lesson every developer needs to learn. The amount of duplicate, crappy code (across projects) that exists today is overwhelming. In a lot of cases developers don’t even bother to look around. They just want to write code.

Source

Reducing the amount of code in your product should be a goal.

“I hate code, and I want as little of it as possible in our product.” – Jack Diederich

Source

Keep Lean Dependencies

The old adage “don’t reinvent the wheel” doesn’t apply when the wheel comes attached to a locomotive engine.

Source

Stop Writing Classes

The signature of “this shouldn’t be a class” is when the class has two methods, and one of them is the constructor. Any time you see these signs, you probably should have just written a function.

– Jack Diederich

Source

Reinvent the Wheel

Inventing your own wheels gives you a deep appreciation and understanding of how wheels work and what makes a good one.

Source

Refactoring > Rewriting

Common Excuses For A Software Rewrite

  1. The Code Sucks
  2. “We’re So Much Smarter Now”
  3. We Picked The Wrong Platform/Language

Why Rewriting Is (Almost) Never A Good Idea

  1. It Always Takes Longer Than You Expect
  2. Markets Change
  3. Existing Customers Become Frustrated
  4. Refactoring Can Cleanup The Code
  5. You Don’t Control The Rewrite, It Controls You

Source

Rewriting > Patching

If you are changing more than 25% of a class or method, consider simply rewriting it. You will write the code more cleanly.

Forget new features, Just do the same stuff better.

The problem: it is too easy to lose sight of what users often care about more, which is the performance and usability of the applications and features they already use most often.

– Tim Anderson

Source

Plan, Plan, Plan.

It is much cheaper to do it correctly the first time than to redo it later on. The sooner a problem is identified and fixed, the cheaper it is to do so.

“The general who wins a battle makes many calculations in his temple before the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to win or lose.”

“Plans are worthless, planning is invaluable.”- Sir Winston Churchill

For this to work, everyone involved has to listen, everyone has to be open, everyone has to be responsive. Or we could keep flailing away with the fucked up attitude that “it has to be this way” because the sacred project plan says it’s this way. Because that really is a lot of fun, isn’t it?