Engineering Fundamentals
What actually makes software hard to change, and why the cost of the next change — not elegance, not pattern count — is the thing design is optimising.
Not size, not age, and not ugliness. A change is expensive when the knowledge it touches is spread across places that do not know about each other.
Design decisions are bets on which changes arrive. The bet is priced in indirection now against edits later, and it can lose.
Requirement, constraints, invariants, responsibilities, boundaries, interfaces, state, dependencies, failure, implementation, tests, feedback, evolution — in that order, because each answer constrains the next.
Three different grains, three different reversibility profiles. Confusing them is why teams argue about folder layout as though it were a scaling decision.
Whether you can understand one piece of code without loading the rest of the system into your head. It is the property that decides how a codebase feels to work in.
Design has no intrinsic virtue. Every structural claim in this domain has to cash out as a change that got cheaper, or it is decoration.
Structure is an investment against future change. Where there is no future, it is pure cost — and knowing which code that is, is part of the skill.