Funny how we ended up needing more programmers than ever.
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.
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.
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.)
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.