The best software I have owned is the software I wrote the least of. Small scripts, small utilities, small services with a single clear verb. I still maintain tools from a decade ago that fit in a single file. I have rewritten every large application I have ever shipped.
There is a survivorship bias here — the small tools that didn’t survive are forgotten — but the pattern is real. The five disciplines below are what, in retrospect, the survivors have in common.
One input, one output
A tool with two inputs and two outputs is not one tool. It is four tools entangled. Split it before you ship it.
Stable interface, swappable guts
The parts of your code that the outside world touches should be the most conservative part of the codebase. Everything behind that line is yours to rearrange. The moment you find yourself negotiating with callers about implementation details, you have lost the boundary.
Boring dependencies
Every dependency is a promise to track upstream changes. Pick libraries that are likely to still exist, unchanged, five years from now. Prefer the standard library. Prefer code in the language you already use. Prefer zero dependencies over one dependency, and one dependency over two.
A readme that is a letter
Write the README as a letter to the person who will inherit the tool — which is probably you, in three years, after you have forgotten every assumption. State what the tool is for, what it isn’t, how to run it, and what will surprise you. Nothing else.
An end-of-life plan
Decide, up front, under what conditions you would retire the tool. Write it down. When the conditions arrive, retire it. A tool that cannot be killed is not a tool — it is an obligation.
A tool that cannot be killed is not a tool — it is an obligation.