It is already like that in the enterprise, where certifications are the entry point for certain partnerships.

As engineer I find there should be a baseline.

I also don't expect weekend cooks to keep a Michelin restaurant running.

I don't like car analogies.

A software engineer is like a plumber you link up lots of small components, weld them together and then the data flows through the application (at least that is the idea).

I don't like either of these analogies. Work of SE is much more complicated. I guess a developer who just mashes things together on the front end is kind of like a plumber.

However, if you work with the backend, you need to worry about data access, any concurrency issues, performance problems. Generally tradesman follow relatively simple guidelines, which may change at a slower pace....tech on the other hand changes insanely quickly.

You don't "need" to do any of that on the back-end either to launch a product. Not sure what distinction between FE and BE you think there is here. One messes up an application on the server, the other messes up an application on the client. And there are plenty of avenues for being a clueless plumber on the backend, like using Ruby on Rails + "gem install devise" for authn + "gem install carrierwave" when the boss tells you they want avatars, without having much idea how anything actually works.

> I don't like either of these analogies.

I think it's hard to find a good analogy because software is an incredibly organic and artful thing. It can be highly technical but also playful.

I think it's a matter of finding the right people for the right job, and making sure those people have some skin in the game. If there is no incentive to write quality code, or the dev's don't care to write quality code you probably won't get quality code.

Then again maybe we still haven't come across the correct tools for the job that make it easier to produce quality software.

The fundamental architecture of a car has been relatively the same for many years now. To a lesser extent we see that in computer hardware however in software it so easy to invent new tools that maybe the good tools get lost in the mess of it all.

That happens already. As things stabilize you tend to value predictability. You can have 6-10 smart people do the architecture and design work that drives the work of hundreds of developers.

Programmers want programming to be about ideas, but many/most problems are applying patterns to process.