Yes, this industry is still very young. Another way to think about it is that we still build software the way they built cars in 1905 - to a large extent, most products are build from scratch by hand to serve a very specific set of requirements.

Admittedly OSs, compilers and frameworks are significant steps forward from pure Assembly language, but we're still a far cry from how autos are built today: automakers build a "car platform" by composing different systems, which themselves are composed of assemblies and sub-assemblies and so on. The platform is then targeted towards a specific application by bolting a car body on top, this body is usually separate from the core engineering systems of the car.

A software product is a copy of runnable software installed on a computer. The vast, vast majority of such products are built the same way cars will be built in 2055: entirely automatically, with automatic testing and verification, with no human intervention whatsoever.

It's generally only when we are designing a new piece of software that has to handle a new set of requirements that we start building things by hand; but even then, we almost always use assemblies and sub-assemblies called "libraries" to get the bulk of the design. Then we run the design through a compiler and linker, which automatically manufactures a runnable copy of the software, and then we test it.

Mathematics builds new theorems the same way we build new software and the same way General Motors builds new car blueprints. This is likely to change somewhat as car manufacturing becomes more similar to writing software.

His mention of formal methods is interesting, because up to at least as 2000, academia has tried to instill this in their students. (Or at least tried to instill in me and my fellows.) I remember being taken to task in middle school by my instructor for writing a BASIC program via experimentation and incremental changes, instead of planning it out ahead of time. Yet, some time between my getting my undergrad degree and now, colleges started to drift away from the theoretical to the “practical” approach I’ve done since childhood, at least according to what I’ve read hear and heard about my college since.

It seems like some kind of tug-of-war or back-and-forth is happening now between the two camps, rather than the unification the article writer seems to want or expect.

EDIT: I just realized his conclusion about the “legitimacy of complexity” is part of the problem. I read and hear all the time how clients seems to under-appreciate the efforts required to get software to work. We may never get our house in order until the outside world accepts that the profession has more in common with law or medicine than construction or plumbing. (I’m not quite clear if this is actually a problem all engineering domains have to deal with, or if it is unique to CS/IT.)

I actually think software engineering has quite a bit in common with construction. We both work off blueprints, we have certain regulations that our creations have to adhere to, and we acquire skills as we gain experience that allow us to shortcut the conceptual underpinnings of the work of creation. A framer, for example, should have a rudimentary understanding of physics. They should know why certain shapes are strong, and how much load a given frame can bear. As they gain experience, however, they begin to recognize shortcuts. A joist in one circumstance should be 6x8", 10x14" in another. The knowledge of which implementation needs each size is not, however, rigorously determined or proven. The framer knows from experience which is required.

The same is true of software engineers. We gain, through experience, the knowledge as to what solutions are suitable for a particular problem. In general, however, we don't arrive at this knowledge through rigorous proofs. We arrive at it by empirical testing, and figuring out which solutions work best in a given scenario. Just as the framer is generally unconcerned with the principles of architectural engineering for the business of building a house, so too is the software engineer generally unconcerned with the theoretical underpinnings of their code when it comes to building a product. Certainly, if one is designing a new non-relational database language, or a new search algorithm, then you'd better have a very good grounding in theory. When it comes time to implement them, however, we generally accept that they are theoretically correct and concern ourselves with making it work in the real world. In the same way, a framer will generally accept that the architect knew what they were doing, and not concern themselves with the theoretical correctness of what they're building.