Trade-Off Analysis
Simplicity, performance, reliability, cost, security, time, maintainability. Matrices without fake precision, reversible against irreversible, deciding under uncertainty.
"Which is better?" has no answer; "better at what, and worse at what?" does. Every engineering choice moves along simplicity, performance, reliability, cost, security, time and maintainability at once, and the move is naming which ones this decision actually touches before comparing anything.
Simplicity, performance, reliability, cost, security, time, maintainability — each is a question you can ask of a design, with an observation that would answer it. The move is turning the axis names into questions for your system, and noticing which questions this decision does not change.
A matrix of options against axes is useful for seeing which axis the argument is really about — and dangerous the moment the numbers are added up. Monolith against microservices on simplicity, scale and operational cost, scored as positions rather than measurements, with the caveat the numbers cannot contain.
Renaming an internal function costs a minute to undo; a public API, a database schema, a partition key and a cloud architecture cost progressively more — some of them almost everything. Spend decision effort in proportion to the cost of reversing, and make the expensive ones as late and as small as you can.
The evidence is not in and the decision cannot wait. The move is not to guess harder: take the current evidence, make the best choice that is cheap to reverse, build the feedback that would tell you it was wrong, and adjust — a loop, not a bet.
A decision written down with the evidence, the alternatives, the reason, the assumptions and when to revisit is a decision that can be re-made on purpose. One that lives only in the code is re-argued every time the code surprises someone.