The OODA Loop: How to repeatably identify and overcome the worst technical debt

Technical debt isn't always immediately obvious from a far, but easily recognizable when you touch it: it feels bad. Its a broken abstraction – a manual work-around. Its a burden. Its embarassing. You scratch your head wondering how you got here and how to never get here again. It is often so woven into your particular workflow that off-the-shelf or external solutions don't seem to apply – its isolating.

I've worked with dozens of teams and here's the comforting news:

Look at the product on your left.

Now look at the product on your right.

Don't worry – they both have technical debt, the same as you do.

Tech debt is an amorphous things. Hundreds of thousands of words have been put toward defining it. Here's my definition:

Your worst technical debt is a toll bridge. You pay that toll every time you make a change. In the worst cases, its a closed toll bridge with a cost so high that it prevents you from being able to make advantageous decisions or travel beneficial routes.

Not all debt is created equal. Some debt is good debt - the cost of holding the debt is less than the cost of paying it off. Your job as a lead is to identify the bad debt and eliminate it – without adding more risk.

The OODA Loop - a model for addressing technical debt

American Vietnam fighter pilot, Colonel John Boyd, is well known for developing a model for decision making called the OODA loop. This model was used to help pilots make split-second decisions in the heat of battle. But its far applications far exceed mid-air dogfights.

It includes these 4 steps:

• Observe
• Orient
• Decide
• Act

While the OODA model was developed in the high stakes arena of fighter pilot warfare, the OODA model can be used in any realm that is mired in uncertainty.

This means situations where both you AND targets are quickly moving, decisions have risk, and outcomes are unclear. Sound familiar? Any tech leader can immediately feel the commonalities.

Observe

Your first step is to identify the cost of the debt. Where are your "toll bridges"? What processes take too long and cause the most pain? Are there ideas that you have to kill immediately because of your existing architecture? If you do nothing, how will the situation evolve/devolve?

Orient

Now that you have the view of the environment, look at where you stand. Do you have days to address this or months? Are you funded enough to see a technical debt project through? Will you be working on a related feature soon? In Boyd's framework, understanding your current position is the next critcial step in making a decision.

Decide

Plan your approach. Do we start with add'l test coverage and migrate file by file? Or do we address the largest, most hairiest issue first. This often comes down to your team's knowledge, capabilities, motiviation and risk tolerance. If you have a staff or principal engineer who knows how the sausage was made, they may be able to dive into the riskiest debt. If your team is timid, you can build confidence by starting with a smaller, less risky issue.

Act

"A decision without action is pointless, an action without a decision is reckless." this quote from John Boyd is a good reminder that once you've made the choice: its time to act.

This is critical – and often inertia can be a real challenge. I've seen dev teams get stuck in a "OOD" loop (and I've done it too!)

But by Acting, you change the landscape. You create new information, and you can then re-orient and decide again. Re-orienting without action is a waste of time.

Repeat

The great thing about an OODA approach to technical debt is that its a loop. Its a process you can repeat, just like technical debt is constantly changing and its cost evolves with your situation – so too can your approach to resolving it.