Complexity
Essential versus accidental, simple versus easy, and the maxims — DRY, YAGNI, KISS — restated so they say something falsifiable.
Some difficulty is the business rule itself and cannot be deleted, only moved somewhere honest. The rest is your encoding of it — and that part is negotiable.
Easy is about familiarity and how quickly you can start. Simple is about how few things are braided together. They come apart constantly, and most bad designs are the moment someone chose easy and called it simple.
Every feature spends concepts, states, dependencies and failure modes out of a budget nobody is tracking. Tracking it does not make features cheaper — it makes the price visible while the decision is still open.
Do not build features or flexibility for a requirement nobody has. The rule is right often enough to be a default, and its cost is real: the refactor you deferred arrives under deadline pressure.
The simplest design that satisfies the known requirements — which is a different thing from the smallest amount of code you can write by ignoring some of them.
The rule is about a piece of knowledge having one authoritative home. It is routinely remembered as a rule about text, and that misreading produces shared abstractions that couple things which have nothing to do with each other.
Two opposite failures with the same cause — structure chosen without reference to expected change. The symptoms are recognisable, and the right amount is a function of how complex the domain is and how often it moves.