Every few years a new framework promises to change how we build software. Some of them do. Most of them quietly disappear, and the projects built on top of them slowly turn into archaeology: dependencies nobody can update, build steps nobody remembers, documentation that points to dead links.
Meanwhile plain text files, relational databases and small shell scripts keep working. They are not exciting, but they are understood, documented and supported almost everywhere. When something breaks at two in the morning, you can find the answer — because thousands of people hit the same problem years ago.
Novelty is a budget
This does not mean never trying anything new. It means spending novelty deliberately. A project can afford one or two genuinely new ideas; everything around them should be as dull and predictable as possible, so that the new parts get all the attention they need.
- Pick one new thing per project, and write down why.
- Prefer tools with several independent implementations.
- Check how old the oldest unanswered question about the tool is.
- Ask whether you could still export your data if the vendor vanished.
A simple test
If a tool will still be boring in ten years, it is probably a good bet today.
Boring is not the same as bad. Boring means the surprises have already happened to somebody else, and the fixes are written down.
Writes about tools, habits and the quiet craft of keeping things running.
