Applying Best Simple System for Now for Software Design - InfoQ

The common narrative in software teams frames delivery speed and code quality as opposing forces. Teams either meet deadlines by accruing technical debt, or delay launches to build "future-proof" systems that anticipate every possible requirement shift. Daniel Terhorst-North, in his talk Best Simple System for Now at GOTO Copenhagen, rejects this binary, arguing that the real culprit is speculative complexity, not a lack of time or skill. His proposed framework, BSSN, offers a path to ship high-quality software on schedule by focusing on immediate needs over imagined future changes.

BSSN rests on three core pillars, each designed to eliminate unnecessary work while maintaining a high quality bar. First, the system must be "Simple": it contains no extraneous or speculative code, only what is required to meet current needs. For web development teams, this might mean skipping a heavy state management library like Redux when local component state or the React Context API suffices for the current feature set. It could also mean avoiding polyfills for Internet Explorer 11 when analytics show zero current users access the app via that browser, reducing bundle size and improving load performance for actual users.

Second, the system is "future-proof" not because it includes pre-built extension points for every imagined use case, but because its simplicity makes pivoting to new requirements straightforward. Terhorst-North notes that programmers often default to generalizing solutions, wrapping six if-statements in a rules engine, or deploying an internal web app with 10 daily active users to Azure Kubernetes Service instead of a simpler static hosting solution. This over-engineering creates layers of complexity that slow down future changes, especially when those changes move in a direction the team did not anticipate. For UI/UX teams, this might mean avoiding a custom design system with hundreds of components when the current MVP only requires a handful of buttons, inputs, and cards, keeping the codebase easy to modify as user feedback shapes the product's direction.

Third, the system is "for Now": it meets all current requirements, deferring any future needs until they are actual requirements, not hypothetical ones. This aligns with the YAGNI (You Aren't Gonna Need It) principle, but Terhorst-North extends it to cover infrastructure and design decisions, not just feature code. Finally, the system is "Best": all code meets a suitable standard for its purpose. Production code requires telemetry, automated tests, API documentation, and a clear deployment path. For exploratory sketches or prototypes, the bar can be lower, but even these should avoid poor naming, unwieldy functions, or messy file structures, habits that Terhorst-North argues are non-negotiable regardless of context.

Terhorst-North draws a parallel to Terry Pratchett’s Wintersmith, where witches rely on First Sight to see what is really there, and Second Thoughts to check their initial assumptions. Programmers, he argues, have lost their First Sight, trained to see patterns and generalization opportunities where simple solutions would suffice. Relearning this skill requires admitting that even experienced engineers cannot accurately predict future product directions. Terhorst-North, with decades of programming experience, notes that his own ego often leads him to over-engineer "just in case", a habit he only curbs through consistent practice and pairing with other developers who challenge his assumptions.

InfoQ interviewed Terhorst-North about BSSN, and his responses clarify why anticipating future change is a losing game. He notes that products can shift in any direction at any time, citing real-world examples where teams built flexible reporting tools that could not connect to new data sources, or optimized for scale at the expense of data provenance required for compliance. In each case, the team had predicted one future direction, making trade-offs that hurt them when requirements shifted elsewhere. His position is clear: true flexibility comes from keeping systems as simple as possible, not from adding preemptive extension points.

Developer Experience: Shifting Habits and Practices

Adopting BSSN requires a significant shift in how developers approach design decisions, especially for those with years of experience. Terhorst-North notes that senior engineers often struggle more with the framework, as their experience leads them to believe they can predict future requirements. This confidence leads to preemptive optimization, adding interfaces, abstraction layers, or scaling features that never get used, all while slowing down current development.

The core practice for building BSSN instincts is repetition. Terhorst-North advocates for "faking it until you make it", acting as if the simple solution is the right one until experience proves otherwise. He relies on test-driven development, version control, and frequent refactoring to ensure that any design choice can be reversed quickly if requirements change. Pair programming plays a key role here: a partner can spot over-engineering in real time, stopping gold-plating before it becomes embedded in the codebase.

For web framework users, this means choosing the current stable version of a library like Vue 3 or React 18, rather than waiting for a future version or over-engineering code to be compatible with a hypothetical next release. It could also mean avoiding complex build tools or bundlers when a simpler setup like Vite or even static HTML suffices for the current project. The key is to trust that simple code is easier to upgrade later than complex code with unused abstraction layers.

Framework version decisions are a common pain point where BSSN applies. Teams often delay upgrades or over-engineer code to support multiple framework versions simultaneously, wasting time on compatibility for versions their users do not use. BSSN directs teams to support only the framework versions that current requirements demand, reducing maintenance overhead and allowing faster iteration.

User Impact: Faster Delivery, Better Experiences

The end user is the ultimate beneficiary of BSSN, even if they never see the codebase. By avoiding speculative complexity, teams ship features faster, since they are not spending time building components, infrastructure, or support for hypothetical future needs. This means users get access to working software sooner, with fewer delays from over-engineering.

From a UI/UX perspective, simpler codebases are easier to modify as user feedback comes in. If a team builds a complex component library upfront, changing the design of a button to improve usability requires updating multiple abstraction layers, slowing down iteration. With BSSN, the button component is simple, so changes take minutes, not hours, allowing teams to respond to user testing results quickly.

Performance impact is direct here. Unnecessary code from speculative features increases bundle sizes, adds extra JavaScript to parse, and slows down page load times, all of which hurt user retention and conversion. By only including code needed for current requirements, teams reduce payload sizes, improve Core Web Vitals, and deliver a faster, more responsive experience. For example, skipping a heavy animation library when CSS transitions suffice for current UI needs cuts down on load time, especially for users on slower networks or mobile devices.

Browser support decisions also tie directly to user impact. Adding polyfills for browsers with no current user base wastes resources and slows down page load for actual users. BSSN directs teams to focus browser support efforts on the browsers their users actually use, improving compatibility where it matters, rather than spending time on edge cases that do not affect the user base. This targeted approach reduces the amount of unnecessary code shipped to users, improving performance for the majority of the audience.