Best Simple System for Now | Dan North & Associates Limited<br>Best Simple System for Now<br>Table of Contents<br>3 Feb 2025
26 mins<br>programming<br>software<br>agile
You can have your cake and eat it, as long as you bake it carefully.<br>‘We can do this the quick way and pay later, or the thorough way and pay now.’ This seems to be a fundamental dichotomy in software development, between ‘perfectionism’ and ‘pragmatism’, but I do not think it has to be a trade-off at all.<br>A CTO friend uses the metaphor of clearing two paths up a mountain. The left-hand path is quick and dirty, cleared with a machete and brute force—you do not expect anyone to follow you, you just hack your way through—but you make progress quickly. The right-hand path is a wider, clearer, paved path, and more substantial, but takes time to build as you go along. The left path is useful for scouting ahead to see what is coming up along the trail. The right path is where you will lead everyone, knowing that the trail is safe.<br>My friend lives in a constant tension between folks who take the left path—which also happens to be the fastest way to make money (he works in a trading firm so this argument carries a lot of weight!)—and the right-path folks who want to build a resilient, sustainable product.<br>This describes many organizations I have worked with. The tensions on either side are based on the idea that the ‘other way’ is doing it wrong. The right-path advocates are worried that the left-pathers are racking up technical debt that is going to come back and bite them, under the guise of ‘pragmatism’. The left-path folks think the right-pathers are ‘perfectionists’, over-engineering and gold-plating things (and there are often plenty of business managers lining up to agree with them).<br>I propose that there is a middle path both sides are missing. I call this path the Best Simple System for Now , or BSSN. It has taken me a long time to formulate this idea, which has been ‘hiding in plain sight’ for many years. There are several source ideas that either imply this or at least hint at it, which I hope to acknowledge here, but I have never seen it stated explicitly. So here it is.<br>Characteristics of the Best Simple System for Now<br>The Best Simple System for Now is the simplest system that meets the needs of the product right now , written to an appropriate standard . It has no extraneous or over-engineered code, and any code it does have is exactly as robust and reliable as it needs to be, neither more nor less.
Each part of the phrase Best Simple System for Now is deliberate and each part is mutually reinforcing. Any deviation in any of these means it is no longer the Best Simple System for Now, but something strictly weaker. Let’s unpack each of these parts.<br>for Now<br>The system should not anticipate the future in any way. This is counter to pretty much any advice I have ever received—or given—as a programmer!<br>When we programmers get our hands on a problem, we bias towards a general solution. There is even an xkcd about it, so it must be true:
We are never more than a small leap away from ‘It’s a rules engine!’ or ‘It’s a state machine!’, so our efficient engineering mind decides to save some time—and rework—and reach for this solution right away. Part of this decision is the knowledge that each change carries cost, so taking several small steps to get somewhere is always going to be less efficient than taking the one big step we ‘know’ that we need.<br>We rely on automatic and unconscious pattern-matching to make room for conscious processing. In Thinking Fast and Slow, Daniel Kahneman refers to these as Systems 1 and 2 respectively. Pattern matching is an unconscious System 1 activity; we are good at it and it comes naturally. ‘Seeing what is really there’ is harder and requires conscious thought and effort.<br>Designing for now is the antithesis of this. It is the art of seeing what is really there in spite of the patterns that your brain is presenting to you. This is the crux of the BSSN—which might be pronounced ‘bison’, as a companion to all those yaks we usually end up shaving.<br>Simple<br>When I am designing something, there are two versions of me, usually in conflict. The ‘clever’ version of me—the one with the decades of experience and the big ego–knows that this thing over here will change next, so we should make that thing an interface. Or that we will almost certainly have this volume of data so we should go ahead and build this concurrent version of the processing algorithm instead of the straightforward serial one. The more humble me knows that I will be close-but-wrong with any of my predictions, in the way I have been close-but-wrong so many times before, so maybe hold off for now. The more humble version usually loses.<br>So when the future happens, I end up in one of two modes: either...