Engineering Decisions
Trade-off matrices, decision records with revisit triggers, refactor versus rewrite, build versus buy, and what a framework charges for what it gives.
Six axes that real design decisions move, scored side by side — useful because it forces every option to be described on the axes it is worst at, and dangerous because the digits look like evidence.
Context, options, decision, why, consequences, revisit trigger. Short enough to write in fifteen minutes, and worth writing because in two years the code will not say what was known when it was chosen.
A decision that was right becomes wrong when its assumptions change, and nobody is watching the assumptions. Naming the evidence that would flip the answer is the cheapest engineering practice there is, and the least used.
Five questions decide it: can the behaviour be characterized, can the change be incremental, is the architecture salvageable, how much undocumented domain knowledge is in there, and can old and new run side by side.
Four options rather than two, sorted by how much of the thing you end up owning. The question that decides it is whether this capability is what your product is judged on.
A library is something your code calls. A framework is something that calls your code. That inversion — not size, not scope — is what decides how much of your design it gets to make.
Productivity, conventions and an ecosystem, in exchange for its lifecycle, its architecture, an upgrade obligation and the moments its abstractions leak. All four charges are payable later, which is why only the benefits are visible on day one.
Sort decisions by what it costs to undo them, then spend evidence, meetings and caution in proportion. Most decisions are cheap to reverse and are treated as though they were not; a few are permanent and get decided in a chat thread.