Satisficing vs Maximizing
Herbert Simon won the Nobel Prize in Economics in 1978, partly for this idea: rational humans do not optimize. They satisfice. They find an option that meets their criteria and stop searching. This is not laziness — it is the only rational response to a world where information is incomplete, time is finite, and the cost of searching for the best option often exceeds the benefit of finding it.
The Two Strategies
A maximizer searches for the best possible option. They evaluate every alternative, compare them exhaustively, and choose the one that scores highest. This is the strategy that feels rational. It is also, in most engineering contexts, a trap.
A satisficer defines "good enough" criteria upfront, evaluates options until one meets the criteria, and stops. This feels sloppy. It is almost always the better strategy.
Maximizer approach to choosing a message queue:
1. List all options: Kafka, RabbitMQ, SQS, Redis Streams,
NATS, Pulsar, ActiveMQ, ZeroMQ.
2. Benchmark each one under our load profile.
3. Evaluate operational complexity for each.
4. Compare pricing at projected scale.
5. Read every comparison blog post.
6. Schedule 3 meetings to discuss.
7. Choose Kafka after 3 weeks.
Satisficer approach to choosing a message queue:
1. Define criteria: managed service, handles 10k msg/sec,
team has experience with it, costs under $500/month.
2. SQS meets all criteria.
3. Choose SQS. Move on.
4. Total time: 30 minutes.
The maximizer spent 3 weeks and chose Kafka. The satisficer spent 30 minutes and chose SQS. For most applications, both choices are fine. The difference is 3 weeks of engineering time that could have been spent building the product.
Why Maximizing Fails in Engineering
Maximizing fails for three reasons that are especially pronounced in engineering:
1. The Options Are Too Similar
For most tool and framework decisions, the top 3-4 options are roughly equivalent. The differences between React, Vue, and Svelte matter far less than the code you write in any of them. The differences between Postgres, MySQL, and SQL Server matter far less than your query design. Spending weeks finding the "best" option when all options are good enough is a poor use of time.
Impact of choosing the "wrong" framework: 5% worse
Impact of spending 3 weeks choosing: 3 weeks behind
Impact of building with the "right" framework: Not measurably better
The cost of evaluating exceeds the benefit of choosing optimally.
2. The Future Is Uncertain
Even if you could identify the objectively best option today, requirements change. The workload that favors Kafka now might shift to one that favors SQS in six months. The framework you chose for its server-side rendering might need client-side rendering next year. Optimizing for the current moment is often wasted effort because the moment changes.
You cannot maximize for a future you cannot predict.
You can satisfice for a present you understand.
3. The Opportunity Cost Is Hidden
The time spent evaluating options has a real cost that is rarely accounted for. Three weeks of a senior engineer's time spent comparing message queues is three weeks not spent on the features that generate revenue, not spent on the tech debt that slows the team, not spent on the documentation that helps new hires ramp up.
Visible cost of choosing wrong: Maybe a migration later (days)
Hidden cost of over-evaluating: 3 weeks of lost productivity
(guaranteed, immediate)
The hidden cost is almost always larger.
When to Satisfice
Satisficing is the right strategy for the majority of engineering decisions:
Decision type Why satisficing works
--- ---
Tool selection Top options are similar. Pick and go.
Library choice Any maintained library is fine.
Process design Try something, iterate. You'll change
it in 3 months anyway.
Meeting format Try standups. Adjust based on feedback.
Sprint length Pick 2 weeks. Change later if needed.
Code style Pick a linter config. Enforce it.
The specific rules matter less than
consistency.
Internal API design You control both sides. Iterate freely.
Cloud provider selection For most workloads, AWS, GCP, and Azure
(at moderate scale) are functionally equivalent.
The pattern: if the decision is reversible, the options are roughly equivalent, and the cost of evaluation is high relative to the cost of being wrong, satisfice.
When to Maximize
Some decisions genuinely deserve exhaustive evaluation. Satisficing on these is a mistake.
Security
"Which encryption algorithm should we use?"
Do not satisfice. The difference between AES-256 and a weak
cipher is not marginal — it is the difference between secure
and compromised. Evaluate thoroughly. Consult specialists.
"How should we store credentials?"
Do not satisfice. Use the proven approach. The cost of being
wrong is a data breach.
Data Integrity
"How should we handle financial transactions?"
Do not satisfice. Double-entry bookkeeping, idempotency, and
audit logs are non-negotiable. The cost of being wrong is
incorrect balances and regulatory consequences.
"What consistency model does our system need?"
Do not satisfice if the data matters. Evaluate the actual
consistency requirements. "Good enough" consistency for
a banking system is not the same as for a social feed.
Irreversible Decisions
"Which primary language should our 100-person team use?"
This decision shapes hiring, tooling, training, and culture
for years. Evaluate carefully. Talk to teams who made
different choices. Prototype.
"Should we go public with this API?"
Once it's public, it's permanent. Maximize the quality of
the contract design.
High-Leverage Architecture
"How should we partition our data?"
The partitioning scheme affects every query, every migration,
and every scaling decision for the life of the system.
Evaluate the options against your actual access patterns.
The Satisficing Checklist
Before starting an evaluation, define your "good enough" criteria. This prevents scope creep in the evaluation process and gives you a clear stopping point.
Example: Choosing a monitoring tool
Good enough criteria:
[ ] Supports our tech stack (Python, PostgreSQL, Redis)
[ ] Has alerting with PagerDuty integration
[ ] Costs less than $500/month for our scale
[ ] Has been in production at companies similar to ours
[ ] Someone on the team has used it before
First option that meets all criteria: Datadog.
Decision: Use Datadog.
Time spent: 45 minutes.
What we did NOT evaluate:
- Whether Grafana/Prometheus is cheaper at 10x scale
- Whether New Relic has better APM features
- Whether a custom solution would give us more control
We did not evaluate these because they are irrelevant to our
current needs. If they become relevant, we can switch (two-way door).
The Paradox of Choice
Barry Schwartz's research shows that maximizers are not only less efficient — they are less satisfied. The more options you evaluate, the more you worry about the options you did not choose. The satisficer picks "good enough," commits fully, and moves on. The maximizer picks "the best," second-guesses the decision, and keeps looking over their shoulder.
In engineering teams, this manifests as:
Maximizer team:
"We chose React, but maybe we should have chosen Vue."
"Let's spike on Svelte just to see."
"Should we evaluate Solid.js? I heard it's faster."
(Six months later, still on React, but with lingering doubt
that saps conviction and slows down investment in the choice.)
Satisficer team:
"We chose React. It meets our criteria. Let's invest fully."
(Six months later, deeply proficient in React, shipping fast,
not thinking about alternatives.)
The satisficer team is objectively better off. Not because they made a better technical choice, but because they committed to their choice and extracted maximum value from it.
Satisficing as a Team Practice
Satisficing works best when the criteria are explicit and agreed upon before evaluation begins. Without explicit criteria, evaluation drifts and maximizing tendencies take over.
Dysfunctional evaluation:
"Let's look at all the options and pick the best one."
(No criteria defined. Every meeting raises new considerations.
Decision takes 6 weeks.)
Functional evaluation:
"Here are our 4 criteria. The first option that meets all 4 wins."
(Criteria are concrete and measurable. Decision takes 2 days.)
The leader's role is to set the criteria and enforce the stopping rule. When someone says "but what about option X?" the answer is "does our current choice meet the criteria? Then we're done."
Common Pitfalls
- Satisficing on one-way doors — using "good enough" reasoning for irreversible decisions like public API design or security architecture. These deserve maximizing.
- Moving the goalposts — defining "good enough" criteria, finding an option that meets them, and then adding new criteria because the answer came too quickly. This is maximizing in disguise.
- Confusing satisficing with not thinking — satisficing requires defining clear criteria upfront. That is thinking. The time saved is in the evaluation phase, not the criteria-setting phase.
- Social pressure to maximize — in many engineering cultures, the person who says "let's just pick one and move on" is seen as not rigorous. This is backwards. The rigorous move is to classify the decision correctly and invest proportionate effort.
- Satisficing without criteria — picking the first option you see without defining what "good enough" means. That is not satisficing. That is random. Satisficing requires standards.
Key Takeaways
- Satisficing means defining "good enough" criteria and choosing the first option that meets them. Maximizing means exhaustively evaluating all options to find the best. Satisficing is usually the better strategy for engineering decisions.
- Most tool, framework, and process decisions have roughly equivalent top options. The cost of extensive evaluation exceeds the benefit of choosing the optimal one.
- Maximize for security, data integrity, irreversible decisions, and high-leverage architecture. These are domains where the cost of being wrong is catastrophic.
- Define "good enough" criteria before evaluating options. This prevents evaluation drift and gives a clear stopping point.
- Commit fully to satisficed decisions. The value of a "good enough" choice you invest in fully exceeds the value of the "best" choice you second-guess forever.
- The hidden cost of maximizing is the opportunity cost of the evaluation time, which is almost always underestimated.