Is It Time to Rethink Globalized Supply Chains?

What we're seeing is conflicting priorities.

After things normalize, we'll probably go back to just-in-time, full capacity production.

But there is a real and separate issue to debate w.r.t. globalization, and it has to do with international politics, and how safe it is to put one's well-being in the hands of a rival. Redundancy and efficiency have nothing to do with this argument.

The market, as you note, selects for hyper-specialists, but crises aren't kind to them.

Strictly inferior home-produced goods are better than no goods at all, and the capability to produce them may have systemic benefits (in flexibility, resilience, avoiding certain kinds of path dependence and local maxima) that are not visible when looking at the goods in isolation.

What law and regulation can do is keep a nation on a more generalist footing, and keep it from hyper-specializing too much.

Today the supplier can not only sell to the company but to the consumers directly significantly cutting company's ability to level the price so the company is forced to drop the more expensive suppliers

However the OP meant more than that: that the VW workers, employed for example in Mexico, who assemble cars for US export would get the same worker rights as they would get in the USA.

And the same would hold for pollution at the factory and so on.

Schwinn was another great example of this back in it's heyday. The Chicago factory could essentially produce every part of a bicycle from 1010 steel.

The issue with this model for a lot of companies is that a high level of vertical integration can make it very difficult to pivot. In the case of Schwinn, the change in consumer taste towards lighter bicycles/frames was not something they could adjust to in a cost effective manner; the lighter alloys other companies were beginning to use at the time were not usable in their production process. There were many other factors in their downturn but that was a big one.

> For many years, I've argued against building software you can easily buy or download, but maybe reinventing the wheel is not so terrible if someone wants a company to be long-lived. Primary benefit is the software can be customized for the company's specific needs and not held back by other companies' software, of course. But even if using open source, it can help avoid fad software trends, or the whiplash-speed changing of standard tools/libraries (e.g. the open-source client-side Javascript world).

There's two sides to the 'buy/build' camp that seem oft ignored; The first is that 'build' is a huge cost unknown (i.e. risk) to the business. Maybe you'll build the right solution. Or, maybe it becomes a terrifying project that was put together so haphazardly that they wind up taking the developer's machine and put it in the server room, because they've run out of time and the code doesn't work anywhere else.

But the second... is that a lot of the off-the-shelf software has a specific use case. And the more off-the-beaten-path your business is, the higher the likelihood that you'll have to write customizations to actually meet the requirements. Those have their own set of risks, and I've seen projects where teams have wound up tossing the 'tool purchased by the business' and writing their own thing because it wound up being cheaper to do that than integrate with the muddled mess the company signed a fools bargain contract for (incomplete, poorly documented AGPL clone of a very popular Apache licensed product.)

It's like everything else though; companies want to 'externalize' the cost/risk. And sometimes that works. Sometimes, you have a good contract, with the right carrot+stick SLAs with a vendor, and having that peace of mind that they -will- respond within 24 hours and not use up your own internal developers troubleshooting the in house leetcode.

One of my favorite examples of this paradigm in practice is Job scheduling and/or queueing. Every company I've worked at has had their own 'opinionated' way of doing job. At one, where the requirements were very well defined, the in house library was hilariously bare code and ran on windows scheduled tasks, directories-as-output and at-first-glance terrifying oracle sprocs. But... when you looked at the actual requirements? it did exactly what it had to and no more. The output had to go to FTP, so who cared if it used directories for output as the default? And quite frankly it worked and was simple enough any developer worth their salt could maintain the structure/paradigm.

At another org, that loved to buy/use things off the shelf, I lost many a Sunday to bizarre problems where the combination of Quartz.NET wrappers, MassTransit wrappers, RabbitMQ wrappers.... secondary database queue tables.... just didn't play nice together and would deadlock on the server.