Don’t Do Crazy: A Programming Lesson from the Shipping Industry

Some 90% of global trade moves by sea, making it good odds that the device you’re reading this on has at one time traveled by boat. If it hasn’t, its components probably have, and even if they haven’t, there are always the raw materials they’re assembled from. But with most factories, retailers, and customers are ashore, seaborne logistics pose an interesting puzzle: what’s the best way to move cargo the “last mile” from a lumbering, seagoing behemoth to your door?

“That’s easy,” says the developer sitting next to you. “We’ll just put wheels on the ship so it can drive straight to your doorstep and deliver the goods.”

It’s ridiculous, of course, but programmers pull that stunt all the time. Building software is so much cheaper–usually–than building things in real life that we’re perfectly happy to keep building out new features until we’ve met the letter of the specification. Did the cargo get delivered? Sure. Never mind that gigantic ship-looking thing rampaging through the cul-de-sac on its way back out to sea.

For the sake of argument, let’s assume our newly-amphibious freighter made it through the neighborhood with only minimal destruction in its wake. Then another ship sails into port, and now what?

“Looks like we’re going to need another dry dock, and, uh, another 1800 wheels.”

The good news is that logistics operators already figured this one out. In their thinking, it’s easier to keep ships at sea and trucks on land. Both vehicles in the pipeline do one thing well: one moves an enormous volume of freight and one distributes it to specific points. And there’s a crane in between to connect them.

All of a sudden seaborn logistics seem rather UNIX-y. Rather than matching a physically daunting problem to an equally monolithic solution, operators compose simple, purpose-built parts to get cargo where it needs to go. There’s something to that. Software has an incredible advantage over real-world systems in how fast it is to build, test, and toss, and even lousy designs will often prove redeemable. But it’s even better when they’re well-considered from the start.