In one of his characteristically long essays, Bill Whittle expounded at length on the genius of John Boyd. The essay is political and not necessary to understand my point, so follow the link at your own risk.
At any rate, Boyd proved a tactical theory of aerial combat by repeatedly winning a challenge to the best Air Force pilots in Nevada. The challenger would start by having Boyd in a perfect kill position at thirty thousand feet over the Nevada desert. Once the challenger yelled "Fight’s on!", Boyd had 40 seconds to reverse their positions.
Winning that challenge repeatedly and consistently laid the ground work that allowed Boyd to teach even hardened veterans his combat theories. It opened minds that thought they already knew all there was to know about aerial combat.
And it’s a good thing he did because his theory is counter intuitive. At its heart it claims that making the best decisions doesn’t actually matter in combat. Interestingly, I think his theory might apply profitably to software development.
OODA—Not Just the Sound a Tuba Makes
Responsible action in general follows a very particular pattern—one most of us use all the time without really thinking about it. It’s pretty simple, really, and only the foundation for Boyd’s theory so I’ll be brief in describing it. It’s just four steps.
- Observe-check out the terrain, look at a problem, see an opportunity.
- Orient-figure out where you stand in relation to what you have observed.
- Decide-come up with what you want to do based on your relation to what you have observed.
- Act-take the action you decided upon.
This is pretty basic, really.
Most people who want to make wise decisions will look at this pattern and figure that the quality of your action at the end will depend on the quality of the prior three steps. They’ll try to make the best, most accurate observations possible. They’ll go over their relation to the situation in detail. And they’ll carefully search out the very best action they can decide to take.
Which would probably work out very well in a vacuum.
The Decision Loop
Boyd’s key insight is that actions in a rapidly evolving situation are not a monolithic whole but rather a series of iterations. In combat, you are not the only one taking action and a lot of what you do has to take the activities and movement of everything else on the battlefield into account. Boyd’s insight is that on the battlefield, victory goes to the most agile, not the most prepared, the strongest, or the one with the best technology. Firing at the position somebody held 20 minutes ago is only useful if they are slower than you are.
Boyd’s point was that taking a reasonable series of actions rapidly beats finding the perfect action to take. More importantly, if you are cycling fast enough a bad action becomes less important because it can be corrected in the next cycle. In other words, if you can get three rounds off with 75% accuracy in the time your opponent gets off his single 100% accurate shot, you win.
Evaluating Agile Processes
It’s the word "agile" that piqued my interest while reading Bill’s essay. Agile development has been around long enough that I doubt it’s a new concept to anyone reading this. To me, Agile development can be seen as an expression or form of Boyd’s theories. If this is true (I’m positing the relationship as a theory to explore), then we have an interesting benchmark to use in comparing or evaluating our Agile practices.
It has long been evident that not all Agile implementations are created equal. It turns out that Agile itself is no more a guarantee of success than any other software development tool.
Two Key Refining Questions
In looking at the effectiveness of an agile process, it seems to me that Boyd’s OODA decision loop doctrine prompts two questions that will help expose weaknesses, explain failure, or provide opportunities to improve.
Are we responsible decision makers?
For Boyd’s theory to work at all, you have to have a solid decision making process. Each OODA step has to be taken, in order, and thoroughly enough that the final action isn’t fundamentally compromised. Missing or partial steps lead to random action and while that might keep you alive for a while, it isn’t going to produce actual victory. Anything that prevents you from observing, orienting, deciding, or acting essentially prohibits success. Whether it’s company politics, personal vendettas, or simple incompetence, this lack means that you are pretty much screwed from the start no matter what action you eventually take.
Can we iterate faster?
Once you have a solid OODA loop, the question becomes how fast can you go? I’ve heard of companies that standardize on monthly or even weekly iterations. I’ve wondered for a while why it is that they do so. Oh, I can see that it can be a motivating factor to have a predictable rhythm. And it creates an atmosphere of accountability when you know for certain-sure that you have to push your baby out the door on a known date.
But Boyd’s theory pretty much means that faster is better. Always. My question is if the benefits of a regular schedule are real and if they are, do they outweigh the inherent benefit of iterating faster? Do you really need to create an atmosphere of accountability in your software development shop and if you do, is a regular schedule the only or even best way to do it? Does your software development team need to be motivated by development policy, and if they do, is a predictable rhythm the one or best way to do it?
After all, a regular schedule applied to variable activities means, by definition, that you are padding your activities to meet the schedule. And there are few activities more variable than software development. Indeed, it seems like a classic example of Parkinson’s Law to me.
A Caution and a Caveat
This post is an exploration of my initial thoughts trying to relate a transformative battlefield doctrine to software development. I think it’s a relevant comparison and one that can provide useful insight. I have a personal tendency to make strong statements even when my certainty is relatively low, however, and want to make that explicit in this case. I never begrudge counter arguments and I personally hold no idea inviolate, even when it happens to be my own.
Also, I want to note that while fast iterations might be good for a quality end product, what you do with your product at the end of each iteration needs to be considered carefully. Jay Barnson explains some of the pros of releasing frequent updates with specific relationship to games. Soon Hui recently explored some of the downside. Both include important considerations that are mainly concerned with the business side of software development. I’ll sum up my caution by saying that what is best for your code isn’t always wise to expose to your customers. I think that this applies equally in both in-house software development and software product development.
Frequent iteration doesn’t necessarily mean frequent release.