Applying Best Simple System for Now for Software Design

Ben Linders · article · 2026-05-09 source ↗ Reader 🖥️

Changeability & Optionality Malleable Software Software Design Fundamentals Technical Debt

The trade-off between technical debt and missed deadlines is a false dichotomy; by building the simplest system that meets only current requirements to a high standard (Best Simple System for Now), teams can ship continuously while keeping future change cheap — because simplicity, not speculative flexibility, is the real source of adaptability.

practical · interview-article — An InfoQ article reporting on Daniel Terhorst-North's GOTO Copenhagen talk, supplemented with a follow-up interview. Primarily practical — prescribes a design discipline (BSSN) and offers concrete heuristics for adoption.

Structure

Part	Role
Opening frame: the false dichotomy	Establishes that the perceived trade-off between quality and delivery speed is wrong
The three characteristics of BSSN	Defines the acronym: Simple (no speculative code), for Now (current requirements only), Best (high standard for what exists)
First Sight and Second Thoughts (Pratchett metaphor)	Introduces a diagnostic metaphor — see what is really there, then watch your own thinking
The generalization trap	Diagnoses why systems become complex — programmers love to generalize and predict future directions
Practice and pairing as remedies	Prescribes habit-building through repetition and pairing to counteract over-engineering instincts
Interview: dimensions of change	Provides concrete examples of how speculative design fails when the actual change dimension differs from the predicted one
Interview: act your way to new thinking	Argues that belief in BSSN follows practice, not the other way around — especially for experienced engineers

Key terms

Best Simple System for Now (BSSN) Software Design Fundamentals
A design approach where code meets all current requirements to a high standard, contains no speculative or extraneous code, and is future-proof through simplicity rather than extension points
dimensions of change Changeability & Optionality
The multiple, unpredictable directions in which a product could evolve at any time; anticipating one dimension introduces speculative complexity that trades off against all the others
First Sight Software Design Fundamentals
The ability to see what is actually there — the real requirements and real system — rather than what you expect or wish to see (borrowed from Terry Pratchett)
gold-plating Software Design Fundamentals
Adding unnecessary polish, generalization, or speculative features beyond what current requirements demand
sketches Malleable Software
Exploratory code written to test ideas, held to a lower standard than production code but still requiring good naming and simplicity

Propositions

explicitThe trade-off between technical debt and missing deadlines is a false dichotomy.
explicitWith the right design decisions, you can have a shippable product all the time while keeping quality high.
explicitcontestedSpeculative code and extension points make future changes harder, not easier, because the actual direction of change is unpredictable.
contradicts ←Worse is better: C# versus F# · p19 — Seemann treats F#'s larger, admittedly unmeasured feature superset as a mark of superiority; BSSN holds that speculative extension points and unused capability make future change harder, not easier — the same tension the previous 'worse is better' article exhibited with XML's richer standards ecosystem, and left unaddressed here too.
contradicts ←Worse is better: JSON versus XML · p9 — Seemann treats XML's latent, ready-to-use standards (schema/versioning/XQuery/SAX) as a positive reason to prefer the richer format; BSSN holds that speculative extension points and unused capacity make future change harder, not easier — an unaddressed worldview tension, not a rebuttal Seemann makes.
explicitestablishedTrue future-proofing comes from simplicity — a simple system is easy to change in any direction, not just the direction you predicted.
supports ←Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough · p2 — Gall's Law and the 'Best Simple System for Now' future-proofing argument converge from different traditions on the same claim: a simple working system is what preserves the ability to change direction later.
supports ←Worse is better: JSON versus XML · p5 — XML's gradual enhancement — start with plain nesting, add a schema only when a real need appears — is BSSN applied to data-format design: defer formalization and let simplicity carry adaptability. On this proposition Seemann is Beck-aligned, even as p9 pulls the other way.
explicitProgrammers' love of generalization is the primary cause of unnecessary system complexity.
implicitdevelopedExperience makes engineers worse at simplicity, not better, because they become more confident in their ability to predict the future.
extends ←Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough · p6 — Names the specific psychological mechanism (Einstellung effect) behind the same phenomenon the other document observes — that experience/expertise makes engineers worse at seeing simpler or better solutions, not better.
explicitBSSN is a practice discipline that must be learned through repeated experience, not through intellectual persuasion.
explicitPair programming is an effective guard against over-engineering because a partner challenges speculative assumptions.

Arguments

Speculative design is counterproductive strength: high

BSSN resolves the debt-vs-deadline false dichotomy strength: medium

Simplicity must be practiced, not just understood strength: medium

Narratives

→ Illustrates P3 (speculative design fails) and the 'dimensions of change' concept — four real scenarios where a reporting system changed in ways that conflicted with whatever speculative design choices could have been made
→ Literary metaphor that reframes the design problem as a perceptual one — programmers need to see what is actually there (First Sight) and monitor their own thinking for speculation (Second Thoughts)
→ Personal testimony that even the method's advocate struggles with it, lending credibility to P7 (it requires practice) and P6 (experience doesn't help automatically)
→ Vivid rhetorical example of First Sight — challenges readers to question whether their architectural choices match the actual scale of the problem

Questions addressed

⭕ Is the trade-off between quality and speed real or false?
⭕ What does a well-designed simple system look like?
⭕ Why does speculative design fail?
⭕ How can engineers learn to resist over-engineering?
⭕ Why is simplicity harder for experienced engineers?

Gaps

incompleteNo discussion of how BSSN handles genuinely uncertain or conflicting current requirements. The framework assumes 'current requirements' are knowable and stable, but in many contexts they are ambiguous or in flux.
incompleteNo treatment of team or organizational dynamics. BSSN is presented as an individual design discipline. How does it interact with architectural governance, platform teams, or mandated standards that may require speculative infrastructure?
uninformedNo engagement with the large body of work on evolutionary architecture (Ford/Parsons) or fitness functions, which addresses the same problem space — keeping systems adaptable — with complementary but different mechanisms.
closed byComprehension at AI Speed: Building a Context Store for Evolutionary Architecture — Provides substantive engagement with evolutionary architecture and fitness functions (Ford/Parsons/Kua/Sadalage) as a complementary mechanism for keeping systems adaptable, applied specifically to the AI-comprehension problem that the other document left unaddressed.
illogicalMinor tension: the 'Best' characteristic requires telemetry, automated tests, API docs, and automated deployment paths. These are themselves forward-looking investments that go beyond 'current requirements'. The boundary between 'necessary quality infrastructure' and 'speculative code' is not clearly drawn.