I have a folder full of abandoned configuration. Editor setups I spent a weekend tuning, build pipelines that were clever for about four months, a note-taking system with a graph view I looked at exactly twice. None of them failed dramatically. They just kept asking for maintenance, and eventually I stopped paying.
What survived is embarrassingly plain: a text editor with six plugins, a shell I have not reconfigured since the day I set it up, Postgres, and a task list that is a single text file.
Boring means predictable, not old
A boring tool is one whose behaviour you can predict without checking. It fails in ways you have seen before. Its documentation matches the version you have installed. When something goes wrong at an inconvenient hour, the first thing you find is someone who had the same problem in the same version, and the answer still applies.
That is a different quality from age, although age tends to produce it. A five year old library with a stable interface is boring. A five year old library that rewrote its interface twice is not.
The real cost of a new tool
The install is free. The cost shows up later, in places that are hard to attribute:
- Every teammate who now has to learn it, including the one who joins in eight months.
- Every failure that is now one layer further away from the thing that actually broke.
- Every upgrade that arrives on somebody else's schedule instead of yours.
- Every piece of your own knowledge that is now specific to this tool rather than transferable.
I do not think about that list while a tool is still exciting, so I use a rule instead: a new tool has to remove something. If nothing gets deleted, I am not simplifying, I am accumulating.
When new is the right answer
This is not an argument for standing still. Some new tools are worth the entire cost, and they tend to share a shape: they solve a problem you are currently losing to, the improvement is measurable in something you already care about, and the escape route is obvious.
That last one matters most. Before adopting anything I ask how I would remove it in a year. If the answer involves rewriting features that have nothing to do with the tool, then it is not a tool, it is a foundation, and foundations deserve a much slower decision.
The question is never whether a tool is good. It is whether it will still be good on a bad day.
What I actually keep
The stack I have now is small enough to list in a paragraph, and every part of it has survived at least one project that went badly. That is the only endorsement that means anything to me. Something that works when the deadline is comfortable and the tests are green has not been tested.
Nobody is going to be impressed by your setup. The work will be.
Written by
Ari Bennett
Software engineer and writer
I build web software for a living and write about the parts that are hard to search for: the trade-offs, the dead ends, and the small habits that make a codebase pleasant to come back to a year later. A decade in, I still keep a paper notebook next to the keyboard.
More about the writer
