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.”

I’ve spent 37 years shipping production software across financial systems, marketing platforms, and AI orchestration. That framing is comforting, tidy, and wrong.

Why “Pick Two” Is Wrong

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. Industry research supports this pattern too: the DORA State of DevOps reports consistently show that high-performing teams achieve both speed AND stability by investing in quality practices, not by trading between them.

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.

What This Actually Looks Like

A few years ago I was engaged to build a new product offering on top of an existing platform. The offering shared a lot of the foundation of what was already there, but it needed real work: additional features, and a set of performance enhancements to handle the volume of data and traffic the new product would generate.

I gave my client a timeline. Already truncated. Already trimmed for the corners I thought I could live with.

He came back asking me to compress it aggressively, well beyond what I thought was survivable.

He wanted to cut several of the quality features, all of the performance work, and to let some of the operational load be handled manually until the platform caught up.

I pushed back through the channels I had. The reasoning came back the same each time: get it out the door, we’ll iterate later.

We built what he asked for.

The system had operational issues from day one. The performance shortfalls I’d predicted showed up exactly where I’d flagged them. My client had to hire a full-time person to run the manual workarounds we’d designed as a stopgap: a stopgap that became permanent. Every month of that person’s salary was money the “cheap” plan was supposed to save.

Then the downstream stakeholder the whole thing was built for stepped away. After enough months of visible operational trouble, they walked. A meaningful piece of the business, gone, for reasons my client had chosen to accept as trade-offs before he’d ever seen them play out.

The full accounting: a full-time salary they still pay, the stakeholder they lost, the credibility that relationship would have brought them in their industry, and every rework hour spent fixing things I’d tried to build correctly the first time.

A little more planning up front (to understand the real scenarios, to build in the quality controls and performance work that were actually needed) would have saved them all of it. And would have kept the relationship they lost.

Fast wasn’t fast. Cheap wasn’t cheap. They cost more than doing it right, and they cost the thing the whole project was supposed to earn.

That’s Lister’s Law playing out in real time.

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. Google’s SRE book is essentially a book-length version of this argument, written by the team who invented the discipline.

Where This Leads

Lister’s Law tells you why Good matters. It doesn’t tell you where Good begins.

That’s the next question, and it’s the one I answered in Start With Good: Where Quality Actually Begins. Spoiler: Good doesn’t start with testing. It starts with understanding.

For teams building real-time platforms on that foundation, The Three Clocks Framework is the other half of the puzzle. Every real-time system runs on user time, system time, and business time, and getting Good means designing for all three.

---

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