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. For the person holding the original copy, most mistakes would remain part of the game.

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 literal example. Its developers wanted levels far larger than the PlayStation could hold in memory at once. Instead of reducing the ambition to whatever fit naturally, they built custom compression, resource-packing, and virtual-memory systems. Geometry, textures, animation, sound, and code could be moved through the console’s limited memory as they were needed.

The result was not simply a smaller game. It was an ambitious game arranged around the exact shape of its hardware. The technical system and the level design supported each other, like boxes packed in an order that makes the full load possible.

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

The fixed camera was also more than a technical compromise. It framed scenes like shots in a film. It could hide what waited around a corner, show danger that the character had not reached, or leave the player moving toward something outside the frame. A rendering decision became part of the language of survival horror.

Silent Hill is the example I return to most. Its fog limited how far the player could see, reducing how much of the world had to be visible at once. But the fog did not feel like a technical apology. It became atmosphere.

The player could hear danger before seeing it. Empty streets felt uncertain because the fog withheld information. A boundary of the hardware became part of the game’s identity. Removing the limit might have produced a more technically impressive view and 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.

These examples are memorable because the solution does more than remove a technical obstacle. Crash Bandicoot’s resource system supports its visual ambition. Resident Evil’s fixed framing creates detail and tension. Silent Hill’s fog manages visibility and fear. Final Fantasy VII’s additional discs make room for a cinematic scale that became central to the game.

This is the elegance that constraints can produce. Not making something small for its own sake, but making one decision solve several problems.

The cost of easy #

Modern engineering gives us trucks that appear to have no edges.

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 package manager shows how quickly the dependency can enter. It does not show the years it may remain in the system.

This is not an argument against libraries. Writing your own cryptography to avoid a dependency is not elegance. Neither is rebuilding a complex protocol that a mature library already implements correctly. A good dependency can be the smallest truck because it removes more complexity than it brings.

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 minutes 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. We have to draw some of those boundaries ourselves, because an apparently infinite truck can still become impossible to unpack.