Standardization of threads started between private companies around the year 1800, and continued on mixed in with a bunch of other "competing" private company standards. Sick of the lack of a unified standard, William Sellers submitted a paper in 1864 proposing one standard based on an already popular form. Eventually the USG adopted this as a requirement in government contracts, was adopted as United States Standard thread, and later Unified Thread Standard. The standard is maintained by the American Society of Mechanical Engineers and American National Standards Institute.

https://en.m.wikipedia.org/wiki/Screw_thread#History_of_stan...

Get the government to require a standard for all their software and anyone who wants a government contract will have to conform.

Further parts of that story:

- As noted at Wikipedia, wartime mechanisation and the requirements for standard parts to be provided for the new high technology of motorised transport, armour, and aircraft, drove further standardisation.

- The noted socialist and collectivist,[1] Herbert Hoover, provided the final push toward standardisation of weights, measures, and engineering components, as Secretary of Commerce.

It turns out that military needs and government legal authority and purchasing power can do much to promote standardisation which the free market cannot.

A subsequent case emerged during the Vietnam War during which the US Navy, a/k/a the transport and logistics arm of the US military forces, faced a critical problem in delivering supplies and materiel to very underdeveloped South Vietnamese ports. Though there'd been multiple attempts to standardise shipping around a single container size, this proved to be the ultimate nudge which established the TFU, or twenty-foot unit standard. (Now largely seen in its doubled form, the 40-foot shipping container.)

________________________________

Notes:

1. Sarcasm, gentle reader.

Software nuts and bolts are standardized:

    - instruction sets (e.g. x86, ARM)
    - 8 bit bytes (though there are two byte orders)
    - floating point formats and operations
    - programming languages (Java, JavaScript, C++...)
    - standard libraries (Java SE, libc, stl...)
    - OS APIs (Win32, POSIX...)
    - network protocols (HTTP, TLS, TCP/IP, BGP...)
    - data formats (HTML, XML, JSON, MIME, protobufs...)

However the design complexity of software, with potentially dozens of levels of abstractions and millions of lines of code, isn't greatly reduced by using these standard nuts and bolts.

We're currently in the stage when we create all of our own bespoke connectors - glue code. RESTful interfaces are an attempt at solving part of the problem but they still require a lot of hand fiddling to make them work.

While mechanical connectors have existed for millennia, standardized connectors were a set of fairly recent innovations from the industrial revolution [1], with notable standardizations like unified thread as recent as post-WWII. So they're both new and took time for all of the standardizations to settle to what we have now. And the state of mechanical connectors is not static. There is constant innovation. Consider medical, military, and other applications with special demands.

Seen in that light, software is very rapidly standardizing. Like everyone else here, I feel your pain, though.

[1] https://www.nord-lock.com/insights/knowledge/2017/the-histor...

I'd say some things have been standardized quite well - 8 bit bytes, Unicode, http. It's the application layer that isn't standardized.

Those of us experienced in DevOps have been trying to set standards for repo/project structure, deployments, etc. for quite a while, but it seems like every developer has their own idea of what they did the first time they read a blog post about "how to build X app" and then will use a different structure after they consume their next Medium article. Or, even better, they're been "doing it this way for 10 years", or "I heard Facebook/Amazon, etc. does X".

Incompatibility is incentivized monetarily. Everyone wants to build something with a captive audience.

That's a pessimistic view at best.

Could it just be that compatibility is not monetarily incentivized? And incompatibility is not punished by some regulation enforcement bureau?

> That's a pessimistic view at best.

No, it's something that one would be fired as a decisionmaker for not understanding. It's basic.

EU is now forcing tech companies to be compatible. It will take time, but EU is the only major force pushing for interoperability.

It's not just that, it's more born out of ego. Every idiot who can write a CRUD app thinks they're Zuckerberg building the next big thing. Unless you're working in specialized arenas of FAANG, you're not, and that's okay.

This is the correct answer.

McMaster-Carr offers 1,533 different kinds of thumb screws with 27 different thread sizes. https://www.mcmaster.com/screws/thumb-screws/

No software ever works without defining nuts and/or bolts.

Software is language. It is as slippery as all other human languages when you try to pin it down to absolutes.

Because we're still stumbling on what is and isn't a "bad practice" while companies continue to gaslight the developer population and a few consultants and spokesmen have endless discussions on what should and shouldn't happen.

Ergo, there's no incentive to fix it, and every incentive to keep it broken.