Oh boy. This reminds me of the utterly failed attempts of the last 30 years to eliminate programmers. You know, when companies were telling us that creating business software will be as simple as connecting a few boxes on a flowchart, and their intelligent snake oil-driven framework will automatically translate that into working software. Even managers will be able to do that, right?!
Funny how we ended up needing more programmers than ever.
The tooling improved, so that the given tasks could be done even by non-programmers, but then actual programmers were able to use the improved tooling to do more complicated tasks, of which there never seems to be a shortage of, so that's what the industry moved to.
I wouldn't say utterly failed. The tools never completely replaced programmers, but they allowed programmers to be replaced in certain domains.
The obvious example is Excel. Imagine if there were no Excel. How many more programmers would every enterprise needed to hire just to reach the current level of productivity. Every bank, hedge fund, and financial institution would have hired a programmer for every one or two analysts. They hire a few now, but nowhere near the level that would have been necessary without Excel.
Another example is LabVIEW. The interface is basically a board where you arrange your flowchart boxes (virtual instruments in LabVIEW terminology), configure them through the menus, and connect them together with wires to express the flow of data. The mechanical/electrical/... engineer herself designs the programs that read data from sensors, save them, analyze them, and send appropriate instruction to actuators based on them [1]. I have seen entire assembly lines running on LabVIEW. To the best of my knowledge, the entire program was conceived without any input from software engineers. Had LabVIEW not existed, many many more software engineers would have had to be hired by laboratories, manufacturing facilities, and research institutes.
Not every attempt for eliminating programmers has been successful, but to call all of them snake oil-driven is incorrect. The field of software engineering is young and has not stabilized yet. I would expect that in the coming decades, increasingly more products would be created to replace specific uses of software development. The demand for programmers in those segments would fall. The question is, would the demand in new ventures and markets increase enough to completely neutralize losing those segments? That remains to be seen—with a field as young and rapidly-evolving as software engineering, historical trends do not tell much about the future.
[1] I should perhaps add that I am a mechanical engineer who also codes.
In all fairness, business would be wise to dispense with much of the pointlessly low-level technology it uses. You want to automate a business process? Then formalize the business process itself, not the tool that you think could help you automate it. And do it in a programming language, of course.
High-level programming is only possible once we admit that what we want to do is programming. Too often there's a perception that "configuration" is easier or safer than programming, even when that configuration is Turing-complete.
It's like the web development treadmill. You start out with HTML and some scripting. You build your non-technical users a web site, then an admin page so they can upload pictures and text to their web site. Gradually they request more flexibility and control, until you've ended up reimplementing a crappy version of HTML and some scripting.
Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks".
I think we should endeavor to formalize as much as is reasonably possible, pushing the bulk of the developer work to dealing with the special cases. But even that will eventually result in a small formal core surrounded by layers and chunks of customizations.
> Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks".
The client owns the process - it's their business after all - so they can define it however they wish. I'm not arguing for canned software. I'm arguing for a programming language in which business processes can be defined directly. (I'm aware of the existence of BPMN, ARIS, and other business process modeling tools, but those fall short of being actual programming languages.)
I'm for whatever tools lead to better outcomes (more complete solutions for less cost).
From my experience, however, non-technical decision makers often start from the assumption that the things they want are easy. As such, they tend to be reluctant to invest in new technologies or approaches. In fact, the most common first approach when they become convinced that what they want is actually "big" is to attempt to offshore. In other words, they naively assume that the solution to complexity is more (cheaper) bodies.
So even if a great tool comes along that allows us to meet needs more effectively, it's not guaranteed to be accepted.
Sadly, it was a bubble. While media pushes stories about self driving trucks and cars, big compute is sucking the air out of the it job market at an accelerated pace.
Funny how we ended up needing more programmers than ever.