The Standing Refusal
A piece of software goes years without expanding, and people start describing the restraint as if it were engineered in, like a load-bearing wall you'd need architectural sign-off to move. The changelog stays short. The feature list stays short. Somewhere, the story goes, a founder or a founding document decided what this thing would never become, and that decision has been holding ever since.
That's a comforting story and it's usually wrong. Codebases don't hold positions. A file has no opinion about the next pull request. A product doesn't remember what it turned down last year, because nothing inside it is built to remember; there's no field in the schema for "declined feature." Absence looks like architecture from the outside, but real architecture leaves something you'd have to demolish. Scope discipline leaves nothing. There's just a gap where a feature would otherwise sit, and a gap is easy to mistake for a wall.
What actually happened, almost always, is that a person looked at a request and said no, then did it again the next week, and the week after that. Call it a standing refusal: the same answer, reissued on demand, backed by nothing but whoever currently has the job of giving it. The discipline is a habit performed by whoever is answering tickets or reviewing pull requests today, not a property compiled in once and now running on its own. Find out what happens when that person leaves, or gets overruled a single time, or just gets tired of typing the same rejection, and you learn fast whether the restraint was ever structural.
You can watch it happen whenever something small and disciplined changes hands. The feature list that held flat for a decade starts growing within a quarter. Nobody removed a wall, because there was no wall to remove. There was a person saying no, and now there's a different person, or the same person on a worse day, saying yes. The tool never changed its mind. The tool never had one. The mind belonged to whoever stood between the backlog and the ship button, and that person rotated out.
Worth separating this from constraints that actually are load-bearing: a fixed protocol or a hardware limit, something someone would need to formally revise before a feature could exist. Those leave a record. Changing them takes visible, sign-off-requiring work, and that's a fair use of the word design. What gets called design far more often is a queue of identical decisions with no signature on any of them, no ticket that reads "declined, per founding principle," just quiet where a feature would have gone, quiet that the next person can end without asking anyone's permission.
None of this argues against staying small. It argues about where the credit goes. When something stays disciplined for years, the discipline belongs to whoever is currently on the other end of the request, not to a choice made once and left to run. Swap that person out and watch how fast the thing catches up to everyone else's roadmap.
The thing you're admiring for holding a line isn't holding anything; somebody is, and hasn't stopped yet.