The Best Feature Is Sometimes the One You Don't Build

Every feature you ship is a feature you now maintain, forever, or until someone has the nerve to remove it. That second part rarely happens. Features are easy to add and strangely hard to take away, so software mostly grows in one direction whether or not that direction makes sense.

Saying yes feels generous. It feels like helping. Saying no feels like friction, like getting in the way of something someone clearly wants. I understand the pull. I just don't think it holds up over time.

Most feature requests are really requests for an outcome, and there's usually more than one way to get there. The version that involves building something new is often the most visible option, and visibility gets mistaken for necessity. A setting, a toggle, a new screen, these feel like progress. What they actually are, more often than not, is a small tax on every future change, paid quietly by whoever touches the codebase next.

Complexity doesn't arrive all at once. It arrives one reasonable-sounding addition at a time, each small enough to seem harmless on its own. Nobody sits down and designs an overcomplicated system on purpose. It accumulates, feature by feature, until the simplest change requires understanding five things that have nothing to do with what you're actually trying to do.

I've started treating can we avoid building this as a serious question rather than a way of being difficult. Sometimes the answer is no, and that's fine, some things genuinely need to exist. But the question deserves the same weight as how should we build this, not a shrug on the way to an answer everyone assumed from the start.

The features that age best tend to be the ones that were argued with before they existed. Not resisted out of laziness, examined. What does this actually solve. Who does it serve. What does it cost the next person who has to read this code without the context I have right now.

Restraint doesn't photograph well. Nobody demos the feature they didn't build. But it's usually the difference between software that stays legible for years and software that slowly becomes something nobody fully understands, including the people who built it.

Good judgement, more than good syntax, is what keeps a codebase honest. And a lot of that judgement looks, from the outside, like doing less.