Boring Technology

Boring Technology is the practice of choosing tools that are simple, proven, well-understood, and deeply unsexy — and shipping with them while everyone else is still configuring Kubernetes.

The term was popularized by Dan McKinley’s 2015 essay “Choose Boring Technology,” but the principle is considerably older. It was practiced instinctively in 1990 by a boy in Lisbon who had 488 bytes and no choice, and has been practiced deliberately ever since by everyone who learned from that constraint that the best tool is the one that doesn’t make you think about the tool.

“Boring technology. Beautiful results.”
— riclib, The Databases We Didn’t Build

The Manifesto

The Boring Technology Manifesto was articulated in its fullest form on a night when the entire modern development stack was examined and found unnecessary:

IF A DATABASE EXISTS, USE IT. DON’T BUILD ONE.
IF A PROTOCOL EXISTS, USE IT. DON’T INVENT ONE.
IF CODE SERVED ITS PURPOSE, DELETE IT. DON’T MAINTAIN IT.

— The Boring Technology Manifesto, The Databases We Didn’t Build

The manifesto’s corollaries, arrived at through thirty-five years of constraint-driven development:

• The best interface is no interface.
• The best database is one file.
• The best deployment is one binary.

These are not aspirational principles. They are the voice of someone who learned to write directly to a display chip’s brain while it was actively rendering, using 488 bytes of bootblock memory on an Amiga 500. When you’ve made six layers of parallax stars in 308 bytes by hijacking hardware registers, you don’t add frameworks “just in case.” You don’t use microservices “for scale.” You don’t split databases “for flexibility.”

“The best deployment is scp and restart. Everything else is coping.”
— riclib, The Databases We Didn’t Build

The Stack

The Boring Technology stack, as practiced in the lifelog:

Each row represents a decision where the boring option was chosen and the exciting option was rejected. In each case, the boring option shipped faster, broke less, and required no Medium article to justify.

The Mass Hallucination

“Modern development is a mass hallucination. SQLite is modern. It’s actively developed. It just doesn’t need a Medium article every week.”
— riclib, The Databases We Didn’t Build

The hallucination operates as follows: a technology is perceived as “old” or “boring” not because it is inadequate but because it is understood. SQLite handles terabytes. Go compiles to a single binary. Hidden fields preserve state across page loads. These are not limitations — they are solved problems.

The exciting alternative is exciting precisely because it is not yet understood. The Kubernetes cluster is exciting because it requires a course to configure. The microservice architecture is exciting because it requires a conference to explain. Redis is exciting because it requires a blog post to justify adding it to a system whose database responds in twelve milliseconds.

The boring technology just works. Working is not exciting. Working is boring. Boring is the point.

The ImageMagick Incident

During the construction of lg — a markdown indexer built in three days — the question arose of how to generate thumbnails. The Squirrel proposed ImageMagick.

ImageMagick requires brew install imagemagick, shared libraries, PKG_CONFIG_PATH, CGO compilation, and a development environment that understands dynamic linking. It is powerful. It supports 200 image formats. The application needs to resize one JPEG to 250 pixels.

The boring alternative: golang.org/x/image/draw, using CatmullRom splines — the same algorithm Pixar uses, published in 1974 by Edwin Catmull and Raphael Rom. Pure Go. No CGO. No shared libraries. No brew install. No PATH. Compiles with go build.

“We’re not using ImageMagick.”
“Why?”
“Because golang.org/x/image/draw exists. Pure Go. No CGO. No shared libraries. No brew install. No PATH. Compiles with go build.”
— riclib, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite

Pixar-grade image quality, from an algorithm older than the developer using it, compiled into a single binary that requires nothing. Boring. Beautiful.

The Homecoming

The definitive boring technology narrative is the Homecoming: seventy-eight days in a “Borrowed Palace” (Craft’s API, someone else’s UI, someone else’s constraints), followed by three days building the boring thing.

Six commits. 4,196 lines of Go. One binary. SQLite for search. Markdown files as source of truth. FTS5 for full-text search. Wiki-links for the backlink graph. No cloud. No containers. No tracking. No dependencies that require an internet connection to compile.

THE PALACE WAS NEVER NEEDED
THE FILES NEEDED GLASSES

— The Lizard, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite

The file is the truth. Everything else is a lens. The lens is SQLite. The deployment is scp. The restart is systemctl. The monitoring is /health. The architecture is boring.

The architecture works.

The 488-Byte Origin

Boring Technology is not minimalism as aesthetic. It is minimalism as survival instinct.

In 1990, a boy in Lisbon had 488 bytes and no option to add a framework. He couldn’t npm install parallax scrolling. He couldn’t containerize the copper list. He couldn’t scale horizontally across Amiga 500s. He had one chip, one coprocessor, and the understanding that every byte wasted was a byte he couldn’t use for stars.

“No React. No virtual DOM. No reconciliation. No npm install with 847 transitive dependencies. No Docker. Just Go, SQLite, and stubbornness.”
— riclib, The Databases We Didn’t Build

The boy grew up. The constraints changed. The instinct didn’t.

The man has gigabytes now. He still chooses the boring thing. Not because he has to — because he learned, at sixteen, in 488 bytes, that the boring thing is the thing that ships, the thing that lasts, and the thing that lets you sleep at night without a PagerDuty alert waking you up because Redis decided to reorganize its keys at 3 AM.

See Also

• YAGNI
• Gall’s Law
• HTMX
• React
• The Lizard
• The Second System Effect