MARCH 09, 2026

SOLID, KISS,
and First Principles

What survived the build.

I used to treat principles as furniture — nice things to have on the shelf of a personal site. SOLID up top, KISS next to it, First Principles somewhere near the bottom with the other imported goods. Then I started shipping, and each one got tested against a real backlog, a real client, and a real date on the calendar. Most of them survived. A few didn't, in their textbook form.

SOLID — two letters do most of the work

Of the five, Single Responsibility and Dependency Inversion paid back every week. A module that does one thing is a module you can cut out without grief. A dependency injected from above is a dependency you can replace under test. I still use both, every day, without thinking.

The other three — Open/Closed, Liskov, Interface Segregation — show up less often in product work. They matter most when you're building libraries that outlive their first caller. Most of my code doesn't. I'll reach for them, but I don't preemptively design for them.

KISS — simplicity is the hard work

KISS is the one I fight to apply. It's easy to nod at and hard to live. Every feature wants a flag, every service wants a second service, every type wants a generic. Simplicity is a daily choice against those gravity wells.

"The machine does not isolate man from the great problems of nature but plunges him more deeply into them."

— SAINT-EXUPÉRY

I keep a small rule for myself: if a reviewer has to read a paragraph of prose to understand why the code is structured a certain way, the code is probably structured the wrong way. Structure should explain itself. Prose is a smell.

First Principles — only when you can afford them

First-principles reasoning is the most over-quoted tool in software. It is also the most useful, when the problem is actually new. The trick is knowing when it is. Ninety percent of the time you're solving a problem that a million people have already solved, and the honest move is to look for their answer. First-principles work earns its weight in the other ten percent — when the constraints are genuinely weird, the industry's defaults do not fit, or the cost of a wrong abstraction will be measured in years.

The mistake is to reach for it as a style. If you derive authentication from axioms on a Tuesday morning, you've done something wrong. Standing on other people's shoulders is not a failure of rigor — it's the point of the industry having a memory.