Does it reduce your decision workload?

Barry Hennessy — Tue, 09 Jun 2026 15:28:11 +0000

You’re three meetings deep into a build-vs-buy debate. Someone’s waving a comparison spreadsheet. Someone else is citing a blog post from 2019. Nobody’s closer to a decision.

Here’s a simpler filter: does this option reduce our decision workload?

If you see software engineering as decision making, then your decision workload is your engineering workload. Every architecture choice, library pick, and integration path is really a bundle of decisions — and some bundles are heavier than others.

The build vs buy example

Take a familiar fork:

Should we implement this service by plugging together off-the-shelf components, or primarily build it ourselves?

Buying removes decisions you’d otherwise make about individual components. But you still decide how to use them, integrate them, secure them, and operate them. Poor documentation doesn’t always mean more decisions — it means harder ones. Gathering context from thin docs is work. Good docs and proven integration patterns? That’s genuinely reduced workload.

Build it yourself means owning every decision in the stack. But if you’ve done something similar before, documented it well, and already know your tools — you’re not starting from zero. You’re reusing decisions you’ve already made.

Neither path wins in the abstract. The right answer depends on you, your history, and the task. But if you ask does this reduce our decision workload? for each option, the better fit often surfaces quickly.

The pattern

A few patterns that show up when you look at engineering through this lens:

Well-documented dependencies cut context-gathering cost
Reusing past decisions skips decisions entirely
Documenting your own choices makes future you faster
Keeping your code clean can keep your decisions clean
Strong observability and playbooks bring context to you when decisions need to be fast

The list goes on — prototyping practices, operational runbooks, conventions your team already trusts. Once you start looking for decision workload, you see it everywhere.

I explore ideas like this on barryhennessy.com — essays on software engineering, decision making, and the meta-work that makes the work actually work!

If this clicks for you, come read more or tell me what you see when you put your own practices under the same lens - I'd love to know.

DEV Community: Barry Hennessy

Does it reduce your decision workload?

The build vs buy example

The pattern