Photo by Jon Tyson on Unsplash

Code should be Stone Age simple

Daniel Sauble
May 2 · 3 min read

When you want to build something to last a long time, simple things are better than complex things. Arrowheads are simple by nature. Clocks are not.

To maintain a complex thing, the means to maintain it must be simple. The Clock of the Long Now is designed so it can be maintained with Stone Age tools. But what about something even more complicated than a clock? Code is very complex, how could maintaining it be made simple?

Running from source makes it hard to benefit from old code. What if we put the knowledge of how to build the source into the source itself? Better yet, what if we used package management and public registries to make it easy to share and consume what others have written?

Elitism raises the barrier to entry for new programmers. What if we released things as OSS, created friendly communities to help each other, and wrote robust test suites for everything so it’s easy to make changes and understand how those changes impact the rest of the system? What if we put an emphasis on building things that are easy to understand rather than showing off our technical mastery?

Code bloat makes it hard to understand what code does. What if we built self-contained, reusable libraries and frameworks? Better yet, what if we locked the feature set early (TeX-style) to keep these libraries from sprawling into other domains to which they don’t belong?

Shortcuts/magic remove clear affordances for the uninitiated, what if we wrote tools that adhered to KISS and were well-documented?

Platforms that are not web-aware make it difficult to tie into the larger ecosystem of tools, what if we wrote hosted services with clear APIs that other services can interface with?

Monolithic code-bases are large and unwieldy, what if we had separate repositories, one for each self-contained thing?

Publishing can be a complex activity requiring specialists, many interteam dependencies, and hours or days of manual testing. What if every software project had the mentality that anyone should be able to deploy code at any time, with the duration measured in minutes?

Different devices, form-factors, operating systems, and SDKs make it difficult to write cross-platform code. What if we supported standards committees (e.g. W3C) and used the standards they write (e.g. HTML5) rather than reinventing the wheel a hundred times?

Infinite flexibility makes new tools difficult to learn. What if we set a goal of 10 minutes for people to achieve some level of expertise with the tool, and built constraints into the tool accordingly?

Lack of time keeps many people from aquiring the prerequite skills needed to solve a software problem. What if we built tools that a person with nothing but an app idea could use. We have enough tools built for senior developers who have already written a hundred apps.

Overpromising and underdelivering makes software development seem hard and esoteric. What if we scoped our releases rigorously, and consistently released updates on a weekly basis? What if we addressed technical debt up front to avoid six month rewrites of our entire code base?


In a future where products and services outlive the businesses that founded them, will future-proofed design matter more than it does today?

Daniel Sauble

Written by

Product Manager at npm and student of Data Science

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade