The launch status check: a great example of loose design-time coupling

One of the most iconic parts of a NASA space launch is the launch status check (aka. go/no go poll). The flight director calls out to each team, and they respond with their readiness to proceed “TLA is go”. If all teams are ready, the launch proceeds; otherwise, it’s scrubbed.

An example of loose design-time coupling

The launch status check is a great example of loose design-time coupling. Each team is responsible for their part of the launch. Their readiness is determined by their own criteria, which are, at least in the context of the launch status check, encapsulated within their team and not exposed to the flight director.

In essence, their API is

interface Team {
    boolean isGo();
}

This simple API hides the complexity of the implementation. It’s likely to be very stable: i.e. it’s an iceberg!

An example of tight design-time coupling

An alternative launch status check would be one where each team supplies their data and the flight director makes the decision. Each team has an API that exposes their readiness data.

interface TLATeam {
    TLAData getData();
}

With this style of API, there’s little or no encapsulation. Whenever it changes the ‘flight director’ must change in lockstep. As a result, of this insider trading, there’s tight design-time coupling. It’s best avoided and you should instead aim for loose design-time coupling. After all, it’s not rocket science.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help