The Case for Boring Software

Every few years a new framework promises to change how we build everything. Some of them do. Most of them change how we build things for about eighteen months, after which we are left maintaining a system written in a dialect nobody hires for anymore.

Boring software is software whose failure modes are known. It has been run in production by people who were not its authors. Its documentation answers questions you actually have. When it breaks, someone has already posted the fix.

Novelty is a budget

The most useful rule I know is to treat novelty as a budget. A project can afford one or two genuinely new things; everything else should be dull. Spend the budget where it gives you an advantage your competitors cannot easily copy, and nowhere else.

This is not an argument against progress. It is an argument for choosing, deliberately, where you want to be surprised.