Skip to content
sage@afterdark~/concepts/half-life-of-a-tool
·C_03 · CANONICAL
// concept

The Half-Life of a Good Tool.

Every tool decays. The honest question isn't 'is it broken?' — it's 'is the next adoption cheaper than the next workaround?'


// definition

A new tool always feels like the right one in year one. It bends to your shape, you bend to its shape, you build on top of it. By year two you've added five workarounds you don't remember writing. By year three the workarounds outweigh the tool.

Most teams don't decide to switch — they decide not to decide. Each individual workaround is small. The cumulative weight only shows up when someone new asks why the build script needs that one specific Node version.

The decision threshold is a question, not a feeling: at this point, is the next workaround going to cost more than the next adoption? When the answer flips, switch. Don't wait for it to break.


// essays that use this concept