StackOverflow co-founder Jeff Atwood’s post (yep, RWWeb, I found it via Fred Wilson too) on iterating faster because of “OODA” (John Boyd’s fighter pilot strategy that applies to business) is directionally correct but misses some important nuances of OODA for business.

The acronym “OODA” (not OOPA as Atwood says at one point in the post) stands for Observe Orient Decide and Act.  I’ve written about OODA in the past and enjoyed Boyd’s writings on the subject, which are excellent strategy musings.  Given that it is a strategy evolved for fighter pilot dogfighting, it should come as no surprise that it is primarily a competitive strategy.  It’s application to non-competitive problems, such as complexity analysis, seems tenuous at best, though perhaps we can put it down as an additional pattern to use for decision making with incomplete information.

The problem I have with Atwood’s latest iteration of OODA discussion, and it looks like RWWeb author Chris Cameron is similarly bemused, is that it is all too quick to assume that quality has no merit, only speed of iteration.  Atwood’s money quote to that effect is this one which compares Android and iPhone:

Android doesn’t have to be better than the iPhone (and it most definitely isn’t; it’s been mediocre at best until recent versions). They just need to be faster at improving.

If you want to look at it that way, so long as you iterate without respect to quality of iteration, then a random walk is good enough.  But, we know that logic is flawed, because if it is going to win, Android does eventually have to get better than iPhone, or at least close enough that people stop caring.  If we want to get all cerebral about it, we can start thinking in terms of things like Zeno’s Paradox, where as we know, if each successive step is not long enough, we never get to the destination.  This is not a bad model for contemplation of the trade-offs between speed and quality of iteration.  But it is really not that hard if you think about it–unless the overall iterations deliver enough quality (an individual iteration might not) to net gain on the competitor, we will lose.

Going back to John Boyd’s fighter planes, we can jink and weave faster than the other pilot, but unless the jinking and weaving is accomplishing some purpose, eventually we will do the wrong thing, find ourselves in front of the other guy’s guns, and it’s, “Bye, bye, birdie.”

So let’s go back to the essential competitive insight of OODA, and forget about the coarse interpretation that it simply means it is better to iterate fast than to worry about the quality of an iteration.  OODA is all about getting inside the other guy’s decision making process and forcing him to respond to you.  Once he is following your lead, you control the game and as long as you keep things that way, you can win.  If you can Observe, Orient, Decide, and Act such that you worry the other guy and he interrupts his own decision making to respond to what you’re doing, you have accomplished that goal.  You are inside his decision loop and you are now the master.

On that basis, you must not only iterate faster than the other guy, but your iterations must be of sufficient quality and effectiveness that they interrupt the other participant’s plans.

Let’s keep in mind something else too about iteration: each iteration has both fixed and variable costs.  Fixed costs are usually unproductive from the standpoint of delivering some value impactful enough to distract your competitor from their own plans.  Fixed costs are things like whatever it takes to roll a dev version into production, upgrade the users, run the regression tests , and all that sort of thing.  These are things you will do every iteration whether it is long or short.  The shorter the iteration, the greater the proportion of time taken up by the fixed costs and the less time available for variable costs like actually adding any valuable functionality.

Considering the fixed versus variable costs is not an excuse for indefinitely long release cycles which fail for all sorts of other reasons.  But it is a justification for not making cycles so short that you start to cavitate.

Cavitation is another military-inspired term that has good analogies to business.  When a submarine’s propellor turns too quickly it cavitates, and in the process produces a lot of noise, gives away your position, and becomes less efficient at propulsion.  In the worst case, cavitation will even start to tear chunks out of the propellor.  We’ve all seen cavitation at work on a development cycle, and it’s not a pretty sight, especially the part about mkaing a lot of noise with dramatically less forward progress!