From "Just" to an Experiment

From “Just” to an Experiment

In It’s Never Just That Simple I wrote about why “just” is such an expensive word in engineering conversations. “Just add a cache.” “Just swap the library.” “Just rewrite it.” Each one hides the invalidation strategy, the migration, the team that owns the other end of the contract.

That post was about what goes wrong. This one is about what to say instead, because sometimes the quick fix really is the right call. The trouble starts when a guess gets presented as a plan.

TL;DR: Before proposing a quick fix, say your assumption, ask what you’re missing, shrink the blast radius, agree on what success looks like, and know how to undo it. Five sentences, and your idea becomes something the team can test.

The Protocol

Each step is a sentence you can say out loud in a code review, a standup, or an incident channel.

  1. State the assumption. “I think X might work if Y is true.” Naming the “if” gives everyone something concrete to confirm or knock down. Most bad quick fixes are good ideas resting on one wrong assumption.

  2. Ask for constraints. “What am I missing? Has anyone tried this already?” The person closest to the problem usually knows the history. This is where you find out about the migration that failed last year or the client that still depends on the old format.

  3. Bound the blast radius. “Can we try this behind a flag, or on one customer first?” A change that reaches 5% of traffic can be wrong cheaply. A change that reaches everyone at once has to be right the first time.

  4. Define success and failure. “Which number tells us this helped, and which one tells us it hurt?” Agree on it before shipping. Otherwise every result looks like a win to whoever proposed it.

  5. Plan the rollback. “If this makes things worse, how do we undo it, and how long does that take?” If the honest answer is “we can’t,” that tells you how careful steps 1 to 4 need to be.

Walking “Just Add a Cache” Through It

Here’s the same suggestion from the first post, before and after.

Before:

“The product page is slow. Can’t we just add a cache?”

After:

“I think caching the product response could bring p95 latency down, as long as product data doesn’t change often.” (assumption)

“How often do prices update? Has anyone tried caching this endpoint before?” (constraints)

Say the answer is: prices come from the pricing service and change every few minutes, and an earlier cache once showed stale prices during a sale. Now the idea gets sharper instead of dying:

“What if we cache only the description and images, and keep prices live? We could put it behind a flag for 10% of traffic.” (blast radius)

“Success is p95 under 200ms and a hit ratio above 80%. A single stale-content report counts as failure.” (success and failure)

“The flag is the rollback. Turning it off sends every request back to the database.” (rollback)

It’s the same instinct as the “before” version. The difference is that the team can now say yes to it, or say no and explain exactly why.

Why It Works

“Just” quietly hands all the risk to whoever has to implement the change. The protocol splits the risk between the person proposing and the people who know the system.

It also changes what a “no” means. After “can’t we just,” a no feels like a turf war. After “what am I missing,” a no comes with a reason, and you walk away knowing something about the system you didn’t know before.

When to Skip It

You don’t need five steps to rename a variable or bump a patch version. I reach for this when a change touches stored data, a contract another team depends on, or production traffic. In those places, a two-minute conversation is cheap next to a rollback at 2am.

Conclusion

The first post argued that complexity is real and “just” pretends it isn’t. The protocol is the practical half. Keep the good instinct behind the quick fix, and wrap it in an assumption, a question, a small blast radius, a number, and a way back. The next time “can’t we just” is halfway out of your mouth, try “I think this might work if…” instead.

Down the Rabbit Hole

  • It’s Never Just That Simple: Part one, on why “just” does so much damage in the first place.
  • Never Just: A one-page case against the word, handy to drop into a chat.
  • The XY Problem: What happens when someone asks about their attempted fix instead of the actual problem. Step 1 is the antidote.
  • Feature Toggles: Pete Hodgson on Martin Fowler’s site, covering every kind of flag you might use for step 3.
  • Canarying Releases: Google’s SRE workbook on shipping to a slice of traffic and deciding from metrics, which is steps 3 and 4 at scale.
  • Pre-mortem: Imagine the change already failed and ask why. It’s step 2 turned into a meeting format.