Ask an engineer to build the best possible system, and they should look at you blankly. Best for whom? Best at what? Best within what budget, on what timeline, on what hardware, for how many users? The question is incoherent until you supply the constraints.
This is not a quirk of how engineers think. It is the structure of the problem itself. An optimization without constraints has no answer — or rather, its answer is always “more”. More money, more time, more flexibility, more performance. The interesting question is never “what is the best system?” It is “what is the best system you can build within these limits?”
The unbounded problem has no answer#
In optimization, the constraints define the feasible region — the space of solutions that are actually achievable. The optimum is always at the boundary of that region. Without constraints, there is no boundary, no region, and no optimum.
Engineers who treat constraints as obstacles are misreading the problem. The constraint is not blocking the solution. The constraint is the problem. Remove the constraint and you do not get a better solution; you get a different problem.
A team that says “we could build a great product if we had more time” has misunderstood their work. Their job was never to build a great product. Their job was to build the best product they could in the time they had. The constraint was the assignment.
Constraints are not failures#
“We only have two engineers” is not a failure of staffing. It is the size of the team you are designing for.
“We have to ship by Q3” is not a failure of planning. It is the deadline you are designing against.
“The database can only do 5000 queries per second” is not a failure of infrastructure. It is the budget you are designing within.
The constraint is the assignment. Treating it as a complaint changes nothing except your mood.
“If only” is wasted breath#
Engineers spend a lot of energy lamenting constraints. “If only we had more time.” “If only we had better tooling.” “If only the API didn’t have this limitation.”
These statements are not analysis. They are wishes. Wishes do not change the constraint. They only change your relationship with it — usually for the worse.
If a constraint is genuinely worth negotiating, negotiate it. Otherwise, design within it and move on.
Name your constraints first#
The discipline is to name your constraints before you design. What is fixed? What is negotiable? What is the budget — in money, in latency, in memory, in headcount, in calendar weeks? What can you not change?
Until the constraints are explicit, the design discussion is unanchored. Everyone is imagining a different version of the problem.
What is fixed#
These are the constraints you cannot change. The launch date is fixed because marketing has already booked the campaign. The hardware is fixed because procurement takes six months. The legal requirement is fixed because the regulator says so.
Name them. Stop arguing about them. Design around them.
What is negotiable#
These are constraints you might be able to move if the cost is high enough. The scope of the feature. The level of polish. The number of supported platforms. The performance targets.
Negotiate these explicitly when needed — but pick the right one to negotiate, and bring evidence for why moving it is worth the cost.
What is invisible#
The most dangerous constraints are the ones nobody has stated. The implicit assumption that the API must support backward compatibility. The unspoken expectation that this team owns ongoing support. The conventional wisdom that this kind of system uses this kind of database.
Surface these. Write them down. Even if you decide to keep them, knowing they exist changes the design space.
Write them down#
A good design document does not start with the solution. It starts with what the solution must satisfy.
- Performance targets (latency, throughput, availability)
- Cost ceilings (infrastructure, operational, opportunity)
- Compatibility requirements (clients, formats, APIs)
- Operational realities (oncall, deployment, monitoring)
- Time and scope (deadline, must-have features, nice-to-haves)
Once these are pinned down, the solution space becomes a small number of viable points, and the choice between them is a real choice.
Most arguments are really about constraints#
Most arguments about engineering decisions are really arguments about constraints. One engineer is optimizing within an implicit set of constraints; another is optimizing within a different set. They are not disagreeing about the answer. They are solving different problems.
Surfacing the constraints — making them explicit — collapses the disagreement into either alignment or a real, addressable trade-off.
Surface the implicit set#
When two engineers disagree about a design, ask each of them: what are you assuming is fixed? You will often find one is assuming the deadline is hard while the other is assuming the scope is hard. Both cannot be true. The disagreement disappears once they realize they are solving different problems.
Name what you are optimizing for#
The same problem has many right answers depending on what you optimize for. Cheapest to operate. Fastest to ship. Easiest to extend. Most reliable. Each of these leads to a different design.
State the optimization target before you propose a design. Otherwise the design will be evaluated against whatever each reviewer is implicitly optimizing for, and you will never converge.
Beware of unstated stakeholders#
Sometimes a hidden constraint is a person who has not been in the room. The security team will reject this design because it touches PII. The platform team will reject this approach because it bypasses the standard deployment pipeline. The CFO will reject this scope because the cloud bill is already too high.
Bring these stakeholders in before the design hardens. Their constraints are real even if they have not been voiced.
The trade-off frontier#
Within constraints, you are usually choosing between options that trade one thing against another. Faster but more expensive. Simpler but less flexible. Safer but slower. These trade-offs are not failures of design. They are the geometry of the problem.
Get to the frontier first#
A solution is on the frontier if you cannot improve one dimension without sacrificing another. A solution is inside the frontier if some other solution is better on every dimension. Inside-the-frontier solutions are strictly worse — there is no scenario in which you would choose them.
Most early designs are inside the frontier. The first round of review should push them outward, not pick between them. Only once you have several frontier-level options should you start choosing between them.
Then pick a point#
Refusing to choose a point on the frontier — insisting on “all of the above” — is how projects fail. You cannot have the fastest, cheapest, simplest, safest, and most flexible solution simultaneously. The constraints do not let you.
Pretending otherwise is not ambition. It is denial.
The choice between frontier options is a real choice, and it is yours to make. State which dimension you are prioritizing and why. The next person will understand the decision even if they would have chosen differently.
Trade-offs are not failures#
A design that has trade-offs is a design that has understood the problem. A design that claims no trade-offs has either lied to you or has not yet been thought through.
When someone presents a “best of both worlds” solution, ask what it costs. There is always a cost. If you cannot find it, you have not looked hard enough.
Negotiating constraints#
Some constraints are firm. Others are soft, even if they were stated firmly. Knowing which is which is part of the job.
Push back with evidence#
If a deadline is hurting the quality of the work, do not just complain. Show what hitting the deadline costs — concretely. “If we ship in two weeks, we cut features A and B and accept ten known bugs. If we ship in four weeks, we ship all features and the bug count is two.” That is a negotiation. “We need more time” is not.
Pick what to negotiate#
You cannot push back on everything. Each negotiation costs trust and attention. Choose the one or two constraints that genuinely move the outcome, and accept the rest.
Sometimes the answer is no#
A pushback can fail. The constraint stays. That is not a setback — it is information. Now you know the constraint is real, and you can stop wishing it were not.
The mindset#
The engineer who hears “we only have two weeks” and groans is hearing a curse. The engineer who hears “we only have two weeks” and starts asking which features matter most is hearing the problem definition. Same words. Different relationship with constraints.
Good engineering is constrained optimization. The art is in finding the best achievable point, not in lamenting the points you cannot reach.