Lister's Law: If You Don't Pick Good, You Don't Get Any

When people talk about the classic project trilemma — Good / Fast / Cheap — the usual line is: “You can only pick two.”

After decades building software systems, I’ve learned something simpler and harsher:

If you don’t pick Good, you don’t actually get Fast or Cheap.

I’ve watched it play out too many times to count.

• A rushed “fast” project takes months to stabilize.
• A “cheap” shortcut becomes a six-figure refactor.
• Neither ends up fast, cheap, or even usable — just expensive and slow.

That’s why Good can’t be optional.

What Good Actually Means

In software, Good is concrete. It’s not a mood or an aspiration — it’s a set of practices you can point at.

• CI/CD pipelines that catch mistakes before production
• Observability so you know when things fail
• Code you can read six months later without swearing at your past self
• A test suite that gives you the confidence to change things
• Clear boundaries between components so a failure in one doesn’t cascade

Once you have Good, you can choose your optimization. Fast to outpace the market. Cheap to scale efficiently. Either becomes possible.

But without Good, everything collapses under its own weight.

Lister’s Law

I call this Lister’s Law:

If you don’t pick Good, you don’t get any.

Not Good OR Fast. Not Good OR Cheap. Not “well, we can be fast this quarter and fix Good later.”

Good is the precondition — the thing that lets any of it work. Skip it and you spend the next year paying interest on the shortcut. In real dollars. In real time. In real developer morale.

The rare teams that ship consistently — for years, across changing markets, at real scale — have all internalized this. They don’t necessarily call it Lister’s Law. They just don’t skip Good.

---

Have you ever seen a project skip Good and pay for it later? I’d bet you have.