Framing a Design as an Objective Under Constraints

Every problem I have ever worked through starts with the same question: what exactly are we trying to win, and what are the rules we cannot break? That single question is the key to every engineering design challenge I know. Here is the core idea: you pick ONE thing to optimize — the objective — and you hold everything else within acceptable limits — the constraints. You cannot optimize everything at once; that is mathematically impossible when the variables are coupled. Suppose you are designing a pedestrian bridge. As an engineer, I want to minimize total material cost — that is the objective. But I must satisfy constraints: the span must be at least 20 m, the deflection under live load cannot exceed L/360, the factor of safety against failure must be at least 2.0, and construction time must stay under 6 months. The objective tells you what winning looks like. The constraints define the boundary of the feasible region — the space of designs that are even legal to consider. The word "constraint" has a precise meaning here: it is an inequality or equality the design must satisfy. A constraint is NOT a goal; it is a pass-fail threshold. If any constraint is violated, the design is infeasible — full stop — regardless of how good the objective value is. Why only one objective? Because two objectives almost always conflict. A cheaper bridge is usually heavier or weaker; a lighter bridge usually costs more. When two metrics conflict, optimizing both simultaneously yields no unique single optimum — instead there is a Pareto frontier of equally valid non-dominated solutions, and you must either collapse the two goals into one weighted score (a technique engineers call scalarization) or explicitly accept that trade-off. For most design problems at this level, I identify the primary objective, set acceptable thresholds on all other metrics as constraints, and solve. Here is the formulation template I use: Minimize (or Maximize): [objective expression] Subject to: [constraint 1], [constraint 2], ... For example: Minimize total mass of a drone frame. Subject to: natural frequency > 50 Hz, maximum stress < 150 MPa, manufacturing cost < $80, wingspan < 0.6 m. If you tighten a constraint — say you lower the cost limit from $80 to $60 — the feasible region shrinks. The best achievable objective value gets worse (mass goes up) or the problem becomes infeasible. That constraint-tightening trade-off shows up in every real project negotiation I have been part of.