The Bottle, the Box, and Everyone Else

A round bottle has a pretty good résumé.

It holds its contents with relatively little surface area. It can be comfortable to handle. It has been doing dependable work in refrigerators for generations without demanding a firmware update.

Viewed as a single object, it makes a convincing case for itself.

Now put a thousand bottles into boxes. Put those boxes on pallets. Move the pallets through warehouses, trucks, stores, and homes.

Suddenly, the spaces between the bottles matter. Nobody ordered that air, but we are paying to move it anyway.

I call this the single bottle efficiency problem: optimizing one product, user, or interaction and assuming those gains carry through to the entire system.

It is a thought exercise about where we draw the boundaries of a problem. One bottle is easy to inspect. An entire supply chain is considerably harder to put on a desk.

The same problem appears in software engineering. We optimize a request, a workflow, or one customer’s experience, then discover that the improvement becomes expensive when everyone uses it.

Good design requires us to understand both views.

A Better Bottle Depends on the Box

A little geometry explains the tension. For idealized containers with the same capacity and height, a circular cross-section needs less perimeter than a square one, giving it less sidewall area. Assuming equal wall thickness, that can mean less material. Actual bottles introduce shoulders, necks, reinforcement, and manufacturing constraints, but the geometric advantage is real.

Packing changes the comparison. In a large repeating arrangement, circles fill about 79% of the area when placed in straight rows, or about 91% when closely staggered. Squares can fit together without gaps.

Those figures describe ideal geometry, not measured shipping savings. Real bottles have rounded corners, protective packaging, and loading requirements. Still, they explain how a shape that requires more material in isolation can create opportunities to save resources elsewhere.

A more rectangular bottle may allow a smaller carton, better pallet utilization, or fewer shipments where available space is the limiting factor. Those savings can outweigh an increase in the bottle’s own material requirements.

The math has behaved perfectly well. We have changed the boundary around the problem.

Packaging researchers Henrik Pålsson and Daniel Hellström examined 22 supply-chain cases involving manufacturers, distributors, and retailers. They emphasized the value of including requirements from participants who do not select or design the packaging. The people making the decision do not necessarily experience all its consequences. Their paper also discusses sharing costs and benefits across the supply chain.

That last point deserves some attention. A manufacturer might need to spend more so a distributor can spend less. Without a way to recognize and share that benefit, both organizations can make perfectly reasonable budget decisions and leave the better solution sitting in a presentation.

The Truck Gets a Vote

Of course, an appealing explanation still needs to survive contact with an actual truck.

In a life-cycle inventory study of three milk-packaging systems, Jay Singh, Aric Krasowski, and S. Paul Singh found that transport weight limits constrained the potential benefit of efficient packing. The trailers reached their weight limit before they exhausted their space. Systems using reusable crates also allowed lighter bottles and performed better overall than the heavier, independently stackable design under the study’s assumptions.

A beautifully packed truck can still be too heavy. The truck is unimpressed by our diagram.

Square bottles can be better across a lifecycle. They are not automatically better. Manufacturing, product protection, transport, usability, reuse, and disposal all belong in the comparison.

The question is what it takes to deliver the same useful outcome.

Research on food packaging makes this especially clear. Fredrik Wikström and colleagues showed how excluding food waste from an assessment can make an apparently efficient package look preferable even when it leads to greater overall environmental impact. Their approach evaluates food actually eaten, accounting for losses along the way. Packaging with a higher impact of its own can be justified when it prevents enough waste.

Saving a little packaging becomes less impressive if the food ends up in the bin.

A bottle’s job includes getting its contents safely into someone’s hands and allowing them to use those contents successfully. That purpose should stay in the calculation.

Everything Is Fast Until Everyone Logs In

Software deserves the same treatment.

Imagine a shared analytics service. One customer requests a large report. Giving that report every available resource might produce a wonderful completion time. The demo looks excellent. Someone takes a screenshot.

Now every customer requests a large report.

The resources are shared. One person’s faster report can mean another person’s stalled dashboard. A benchmark that looks excellent for a single request can describe a poor service for the userbase.

This is the single bottle efficiency problem with a loading spinner.

Tim Roughgarden and Éva Tardos formalized a related problem in network routing. When users independently choose routes to minimize their own delays, the resulting traffic pattern can have a higher total delay than a coordinated arrangement. Each person can make a sensible decision within the situation they face while the combined outcome remains inefficient.

This is why “everyone should just make the best choice for themselves” is an incomplete architecture document.

For me, the engineering implication is that we should design shared systems so ordinary, reasonable behavior produces good outcomes.

In the analytics example, that might mean separating interactive requests from background work, scheduling large reports fairly, and reusing results when their freshness remains acceptable. A customer may wait slightly longer for one unusually large report while gaining a service that stays responsive throughout the working day.

The individual benefit becomes clearer when we consider their whole day, rather than their fastest possible request.

Someone Still Has to Maintain It

This connects directly to the argument I made in Extending the Reach of Every Engineer. Giving an engineer greater capability creates an opportunity to improve the organization. Realizing that opportunity requires attention to what happens after the individual task.

A change still needs to be understood, reviewed, operated, and maintained. If one person saves an hour by creating something that consumes ten hours of other people’s attention, we should count those hours too. They remain hours even when they belong to a different department.

Shared conventions, reusable workflows, and clear ownership can help individual progress become collective progress. Their value should show up in the experience of the people using them.

A Better Average Can Hide a Worse Experience

Which brings us to the part that rarely fits neatly on the dashboard: a better total does not establish that everyone benefits.

A bottle that packs efficiently but is difficult for someone with limited grip strength to open has a design problem. A shared platform that lowers operating costs while making essential tasks inaccessible to some customers has a design problem.

“The spreadsheet says this is better” is unlikely to comfort the person who cannot open their drink.

We need to examine how benefits and burdens are distributed.

Elinor Ostrom’s work offers a useful foundation. Her research on shared resources describes how communities can develop durable arrangements through participation, rules suited to local conditions, monitoring, and accessible ways to resolve conflicts. The people affected by the rules can help shape them. Her findings also challenge the assumption that one uniform arrangement will work everywhere.

My application of that research to engineering is straightforward and a common one: bring affected people into the design process, especially when their needs are easy to miss in an aggregate metric.

The people maintaining the service need a voice. So do customers with unusual workloads, users of assistive technology, and communities affected by the resources our products consume. They can reveal costs that our measurements never captured.

Five Decisions for a Better System

In practice, I would approach the single bottle efficiency problem through five decisions.

1. Define the useful outcome. For packaging, that might be a liter of product delivered safely and actually used. For software, it might be a customer completing a task accurately and reliably. Choose a unit that includes the purpose of the system. A busy server and a satisfied customer are different measurements.
2. Establish requirements at every level. The individual needs a usable, accessible, dependable product. The user community needs fair access and a service that remains healthy under shared demand. Society has an interest in resource consumption, waste, and consequences that extend beyond paying customers. Make those requirements explicit before optimizing.
3. Follow every displaced cost. A reduction in one budget may appear as work in another. Less infrastructure spending might create more waiting for customers. Faster implementation might create more maintenance. A lighter package might increase damage. For each proposed saving, identify who does less work, who does more, and when the consequences arrive.
4. Give people a reason to participate. Where flexibility helps the system, make that flexibility useful to the person providing it. Someone who can accept a scheduled report might receive a lower price or a dependable completion window. Someone with an urgent need should have a clear path for handling it. Turning savings into shared benefits requires deliberate product and business decisions.
5. Validate under real conditions. Test the bottle through its actual distribution and use. Test the service with competing workloads and different kinds of users. Progressive delivery can help us observe effects before a broad rollout, provided we measure the shared system as well as the participants in the experiment. Track total resource use alongside efficiency per task; cheaper operations can encourage us to run a great many more of them.

Solving the Single Bottle Efficiency Problem

Some decisions will still involve difficult tradeoffs. We should explain those tradeoffs clearly, give affected people a way to challenge them, and keep looking for designs that reduce the conflict.

The ambition should be that an individual gains a product they can use confidently, a community gains something dependable and fair, and society gains from lower total harm and resource demand. Achieving one of those benefits does not excuse us from investigating the others.

The single bottle efficiency problem gives us a way to examine that responsibility: when we make one part better, what happens to everyone connected to it?

We determine where the boundaries of the problem are drawn, whose effort gets counted, and which consequences appear on the dashboard.

The bottle still has to work in someone’s hand. It also has to make sense in the box, on the truck, in the store, and after its contents are gone.

Good engineering follows it all the way.