Problem-Solving Under Constraints
Solving problems under limits of time, resources, and information: satisficing, improvisation, and the Apollo 13 carbon-dioxide scrubber fix.
Problem Solving & Decision Making · Lesson 6
Solving problems under limits of time, resources, and information: satisficing, improvisation, and the Apollo 13 carbon-dioxide scrubber fix.
Real problems rarely arrive with unlimited time, money, or information. The skill that separates people who ship from people who stall is solving well inside the limits, not wishing the limits away. Waiting for perfect conditions is usually a way of never starting.
Constraints are also not only costs. A tight boundary narrows the search, forces priorities into the open, and often sparks more inventive answers than an open budget would. Scarcity, handled well, is a creative pressure rather than a dead end.
A blank page is paralyzing; a boundary gives you something to push against. Limits on materials, time, or budget force you to question assumptions and recombine what is already available. Many breakthroughs come precisely from scarcity — the need to do more with less rules out the obvious, expensive answer and pushes you toward an original one.
Herbert Simon coined satisficing (satisfy + suffice): choosing the first option that clears a good-enough threshold rather than searching exhaustively for the theoretical best. Under real limits, the cost of continued searching often exceeds the value of a marginally better answer. The practical move is to set the "good enough" bar in advance — honestly — and stop the moment you clear it.
Improvisation is disciplined, not random. You inventory what you actually have, define the minimum the fix must accomplish, and combine the available parts toward that goal. The constraint itself — only these materials, only this hour — becomes the specification you design against.
A team must ship a customer-facing status page before a launch in two days, with no budget for new tooling. Optimizing would mean a real-time system wired into every service — weeks of work. Instead they satisfice: they set the bar at "customers can see whether the system is up or down and when it was last checked." They build a simple page that reads an existing health check and refreshes every five minutes, using tools they already own. It is not elegant, but it clears the threshold on time and can be improved later. The constraint forced them to find the true minimum requirement instead of gold-plating.
Constraints do not excuse cutting corners that matter. Satisficing works only when the threshold you set honestly captures what is important; it fails when "good enough" quietly means "we ignored the hard parts." A surgeon or a bridge engineer cannot satisfice on safety margins. The real skill is telling firm floors — requirements that must not be traded away — apart from preferences you can flex when time and resources run short.
In April 1970, an oxygen tank aboard Apollo 13 exploded on the way to the Moon, forcing astronauts James Lovell, Jack Swigert, and Fred Haise to use the Lunar Module as a lifeboat. That module was built to keep two people alive for about two days; now it had to sustain three for roughly four. Carbon dioxide climbed toward dangerous levels. The trouble: the Command Module's lithium-hydroxide scrubber canisters were square, while the Lunar Module's system accepted round ones — they were not interchangeable, a literal square peg in a round hole.
On the ground, engineers in NASA's crew systems division, led by Ed Smylie, had to design an adapter using only items already aboard the spacecraft: plastic stowage bags, cardboard from a flight-manual cover, tape, and a hose from a spacesuit. They built and tested the fix, wrote step-by-step instructions, and read them up to the crew, who assembled the improvised "mailbox." Carbon-dioxide levels fell, and the crew returned safely on 17 April 1970. It is a textbook case of satisficing and disciplined improvisation under extreme limits: not the ideal solution, but a workable one built from exactly what was available, in the time available.
Take a problem with a hard deadline. Write down the honest "good enough" bar it must clear, list the resources you actually have on hand, and describe the smallest fix that would clear the bar. Then name one requirement you must not trade away.
Think Like a Maester: When you cannot have the best answer in time, define good enough on purpose — then build it from what is in the room.
Limited time, resources, and information are the normal conditions of real problem-solving. Treat constraints as design parameters, set an honest good-enough threshold and stop searching once you clear it, and improvise by combining what you actually have toward the minimum the situation requires — as the Apollo 13 team did to bring its crew home.
Mark this lesson complete to track your progress.