Boring is a feature in institutional software

Institutional software has a different success condition from a side project. It succeeds when it is still working two years later, on a Tuesday, while the person who built it is on leave.

That condition rewards boring choices:

• A framework with a long release history.
• A relational database instead of a new storage engine.
• One deployment path instead of three.
• Configuration in one file instead of spread across the UI.
• Logs that answer “what happened at 09:14” without a debugger.

None of these are interesting to talk about. All of them reduce the number of ways the system can fail when nobody is watching.

Novelty has an operating cost

Every new tool adds a category of knowledge that someone has to hold:

• How does it deploy?
• How does it fail?
• Where do its logs go?
• Which version is running?
• What breaks when it upgrades?

For a team of one or two people maintaining a dozen small sites, that cost is the constraint. Adding a new tool is not free because it is free to install.

This is also why I am suspicious of architectural changes that are justified mainly by developer preference. A rewrite is a bet that the new system will be cheaper to operate for the remaining life of the project. That bet is sometimes right. It is rarely as obvious as it feels during the first week.

Boring does not mean careless

The opposite mistake is treating “boring” as an excuse for poor structure. A boring stack with no schema discipline, no validation, and no deployment notes is just an old mess.

What I aim for:

• Explicit boundaries. Where input is validated, where permissions are checked, where data is written.
• One source of truth per fact. Roles, configuration, and content should not be defined twice.
• Operable defaults. Backups, TLS renewal, and log rotation are part of the build, not a later task.
• Documentation that answers the next question. Not a novel — a short page on how to deploy, restore, and roll back.

The test I use

Before adding something, I ask two questions:

1. Does this remove a failure mode, or add one?
2. If I am unavailable for a month, can someone else operate it from what is written down?

If the answers are “adds one” and “no”, the novelty needs a better reason than interest.

That test is not an argument against learning. I am learning Go and container-based infrastructure right now. But learning happens in the lab first. Production is where the boring version goes.