Also it seems like a win-win approach: harder for ships to get stuck, and room for more traffic.
The issue with your analogy is that here the "program" did not OOM as part of normal operations, instead it OOM'd because of a rare condition you can't really avoid (even calling it a bug is debatable, as a bug implies misbehaviour in the canal).
In that case, increasing your safety buffer so you can recover before swapping to death or the OOM killer -9-ing programs left and right is a good idea.
> - You can make the program handle the too-large-data case better. This requires deeper systemic changes usually across multiple components (the program, your monitoring and error reporting, upstream and downstream integrations). But this also tends to have knock-on improvements across the system.
How would you make "the program" handle "the too-large case better" exactly? As in, how would the canal handle a ship getting stuck sideways after having lost propulsion save by being wider than the ship can be long?
> And a lot of times it's cheaper than the first option when you compare total rather than marginal cost.
We're talking about a 200km canal.
> Why fuss over 131x10 feet and not the fact your only recovery plan is one excavator and a handful of tugboats?
Maybe they're working on both but increasing the canal width to provide more buffer in case of rare issues is a much more complicated and thus interesting thing, and thus gets more visibility?
One should identify both corrective measures and preventive measures in equal measure.
- You can reduce the program's memory usage, or increase the program's / system's alloted memory. But there's usually some hard limit to this - if you've got 100GB of data, you've got 100GB if data, and if you've got a non-distributed problem you'll eventually run out of RAM slots. Plus you usually just get induced demand when a customer shows up the next day with 200GB data.
- You can make the program handle the too-large-data case better. This requires deeper systemic changes usually across multiple components (the program, your monitoring and error reporting, upstream and downstream integrations). But this also tends to have knock-on improvements across the system. And a lot of times it's cheaper than the first option when you compare total rather than marginal cost.
Or to be more direct: Why fuss over 131x10 feet and not the fact your only recovery plan is one excavator and a handful of tugboats?