Skip to content

CONCEPT Cited by 3 sources

Simplicity vs. Velocity

A first-class engineering concept in S3's 2025 retrospective: there is a real, two-way tension between shipping a feature quickly and shipping a feature that is simple enough that customers don't have to architect around its sharp edges. Andy Warfield:

"There's actually a really important tension between simplicity and velocity, and it's a tension that kind of runs both ways. On one hand, the pursuit of simplicity is a bit of a 'chasing perfection' thing, in that you can never get all the way there, and so there's a risk of over-designing and second-guessing in ways that prevent you from ever shipping anything. But on the other hand, racing to release something with painful gaps can frustrate early customers and worse, it can put you in a spot where you have backloaded work that is more expensive to simplify it later."

(Source: sources/2025-03-14-allthingsdistributed-s3-simplicity-is-table-stakes)

The self-critical observation

Warfield's sharpest framing:

"In pretty much every example that I've mentioned so far, the improvements that we make toward simplicity are really improvements against an initial feature that wasn't simple enough. Putting that another way, we launch things that need, over time, to become simpler."

Interpretation: most simplification work is simplification debt repayment. The question isn't whether you'll take on this debt — shipping velocity means you will — but whether you can see it clearly, price it correctly, and schedule repayment.

Examples from the S3 post

  • Strong consistency (2020) — years of customers writing eventual- consistency workarounds is the cost side; the 2020 rollout is repayment. Customers reported "deleting code."
  • Conditional writes (2024) — same shape: customers had been building external locking / version-fencing for years; compare-and- set is repayment.
  • Bucket limit 100 → ~1M (2024) — decade of customers building multi-account topologies to work around the cap; repayment required rewriting systems/metabucket, paged ListBuckets, and fixes across tens of services' console widgets.
  • S3 Tables (2024) — Iceberg-on-S3 as a pattern predates Tables by years. systems/s3-tables is deliberately labelled "simplicity vs. velocity decision": launched with known simplification gaps because the earlier status quo (everyone building their own table primitive) was worse.

Compare with Lambda's framing

The 2014 Lambda PR/FAQ picks the opposite end explicitly — patterns/launch-minimal-runtime: "we made the hard decision to only launch with support for Node." That is velocity-first, with explicit pre-acceptance of the debt (more runtimes deferred) and a decision to pay it down under observed customer load.

Both S3 and Lambda agree on the shape of the tension; they differ on where on the curve a given launch sits.

Failure modes

  • Over-design — the perfection trap. Endless review, nothing ships, customers build external workarounds that become the de-facto standard before you arrive (see Iceberg before S3 Tables).
  • Under-design — painful gaps compound, not decay. Every customer integration path that encoded the sharp edge becomes part of the simplification cost later.
  • Hidden debt — the simplicity gap isn't visible to the team because it shows up only at scale, when it's expensive to fix (e.g. the ListBuckets console-rendering problem that only manifested with millions of buckets).

Seen in

Last updated · 200 distilled / 1,178 read