Packing the infinite truck

Imagine that everything needed for a move must travel in one truck.

Capacity and correction #

It is an ordinary truck, and it can return if something is forgotten.

Because the truck can return, packing does not need to be perfect. That is useful. A forgotten box can still arrive. A mistake can be corrected. But the ability to return does not make the second trip free.

The second trip is not a disaster or a punishment. It simply has a regular cost: more fuel, more time, another stretch of driving, and more work for everyone loading and unloading it.

Now imagine that the goal is to avoid another trip entirely. The obvious answer is to hire a larger truck. It costs more than the ordinary one, but everything is more likely to fit. That is also a regular cost. We are buying capacity because we believe it will cost less than returning.

The larger truck solves the immediate problem. It also makes poor packing harder to notice. Half-filled boxes, unused furniture, and things nobody remembers loading can travel together without forcing a decision. Empty space feels free after the truck has been paid for, even though a smaller load must still be driven, unloaded, and sorted from a larger vehicle.

But what if you had only a single small truck, one that would leave once and never return?

Packing changes immediately. If boxes are placed wherever they fit at first, the furniture may not fit later. Smaller boxes can go inside larger ones. Loose objects can fill drawers, cabinets, and gaps between furniture. Packaging that carries no value can be removed, and something less important may stay behind so that the complete load can fit. The order matters because a poor decision near the front can waste space all the way to the back.

The smaller truck forces the people loading it to pack smarter. The constraint forces you to think about the problem.

Constraint-driven design #

If we take an older console, such as the original PlayStation, we find the same visible edges as the small truck. Its memory, processing capacity, and storage medium were fixed. If a scene did not fit in memory, the team could not increase the machine’s capacity in production. If the console could not draw everything a designer imagined, there was no better PlayStation model with more memory or processing power available.

The release itself was close to a one-way trip. Once a game was pressed onto a disc, boxed, and placed on a store shelf, it was effectively final. Corrected revisions were possible, but producing and distributing them was slow and expensive.

The release build carried a different kind of weight because this disc is the game.

Those boundaries did not create one universal style. Different teams packed their trucks in different ways.

Crash Bandicoot is perhaps the most clear example. Its developers wanted to create levels far larger than the PlayStation could hold in memory at once. Rather than reducing their ambition down to fit the hardware, they built custom compression, resource-packing, and virtual-memory systems.

The hardware enforced strict limits, but those limits did not reduce the team’s ambition. Instead, they pushed the developers to think in creative way about how levels were built, packed, and loaded. The technology and level design evolved together, like boxes arranged carefully so that the entire shipment could fit inside a space that seemed too small at first.

Resident Evil made a different kind of tradeoff. Fully real-time 3D environments could not deliver the visual detail its creators wanted, so the game relied pre-rendered backgrounds and fixed camera angles. The PlayStation had less work to perform while each room appeared richer and more atmospheric

The fixed camera was more than a technical compromise. It framed each scene like shot in a film. It could hide what was waiting around a corner, reveal danger before the character reached it, or force the player to move toward something outside the frame. A rendering limitation became part of the language of survival horror.

Silent Hill is the example I return to most. The PlayStation could not render the town far into the distance, so fog concealed its limited draw distance. Buildings, streets, and enemies beyond the visible area did not need to be rendered. The technical limitation reduced the console’s workload while making the town more unsettling.

The fog turned missing information into tension. Players could hear danger before seeing it, and empty streets felt uncertain because the background remained hidden. What began as a way to avoid rendering distant objects became part of the game’s identity. A more powerful machine might have shown more of the town and produced a less memorable game.

Final Fantasy VII shows why the lesson cannot simply be “always choose the smallest truck.” Its cinematic ambition required space, and the game shipped across multiple discs. The team expanded the physical capacity because the result justified the cost.

That was not a failure to optimize. It was a deliberate decision about what deserved to travel. Good engineering can mean packing the small truck brilliantly, but it can also mean paying for a larger one when the value inside it is clear.

This is the elegance constraints can produce. At first, the load does not fit. If every part still needs to travel, the limit forces you to think differently: compress what can be compressed, optimize what wastes space, and reshape or rearrange parts until they fit together. The ambition remains; what disappears is the unnecessary space around it.

The cost of easy #

Modern engineering gives us trucks that appears to be infinite.

Need one small function? Install a library. Need to call one endpoint? Add the vendor’s entire SDK. Need more capacity? Increase the instance size. Each action is easy, and that ease can feel like the problem has been solved.

But importing a large library for one small function is like hiring an oversized truck to move a single box. The box arrives, so the decision looks successful. What remains less visible is everything that arrived with it: transitive dependencies, updates, vulnerabilities, breaking changes, and code that somebody must understand when it behaves unexpectedly.

The question is whether that tradeoff was considered at all.

When capacity looks unlimited, addition becomes the default answer. Another service can be introduced before the existing one is understood. Data can be stored forever because deciding what to discard is harder than buying more storage. A feature can be added because there is room in the release, even though it will occupy testing, documentation, support, and maintenance for years.

Abundance does not remove the constraint. It moves it somewhere less visible. The system eventually runs out of something: attention, clarity, ownership, or the ability to change one part without being surprised by another.

Connected software also makes mistakes easier to patch. That is real progress. A defect no longer needs to remain on every copy of a physical disc. But an easy return trip should not become an excuse for careless packing before the truck leaves. Deploying a correction may take hours while diagnosing the problem, coordinating the fix, and recovering trust costs much more.

The stronger lesson from old hardware is not that we should make modern development painful. It is that a hard edge forces the problem to be understood before more capacity can be used to cover it.

Before adding a dependency, do we need the whole library for this one use? Can the problem be solved clearly with a small amount of code that the team owns? Does the library remove more complexity than its updates and behavior will introduce?

Before adding a feature, does it deserve permanent maintenance? Before storing more data, do we know why it needs to exist? Before expanding infrastructure, does the problem require more capacity, or is expansion simply easier than understanding where the current capacity went?

These questions are the modern version of standing in front of a small truck. They force us to open boxes, remove packaging, combine what can be combined, and decide what does not need to travel.

Elegance is not having the fewest dependencies, the least code, or the smallest server. It is proportionality. The solution should not be much larger than the problem unless the additional weight earns its place.

An elegant system can look effortless after it is built. That is because the difficult work happened before release: understanding the load, arranging its parts, removing what carried no value, and choosing deliberately what would remain.

The original PlayStation gave developers a hard boundary. Modern engineering rarely does. A larger instance, more memory, or additional storage is usually within reach. That flexibility is useful, but it can make the truck appear infinite. Eventually, we may no longer understand what is inside it, why each part is there, or whether we ever needed a truck that large.

The next time you build something, choose a boundary before one is forced on you. If you are testing several SaaS ideas, start with the smallest practical instance and run two or three early applications on it while you validate their markets. Learn to deploy, observe, and manage them together. Scale when real usage requires it, not simply because more capacity is available. Give the same scrutiny to every dependency, service, and supporting application you bring aboard.

Imagine yourself as a PlayStation developer trying to fit the whole game onto a single CD. Keep the ambition, but question the size of every box. Compress, optimize, and rearrange before ordering a larger truck. That practice will sharpen your judgment and make you a better engineer.