The problem with this question is that, if it's not engineering, what is it? A better question is motivated by studying the history of chemistry and its progenitor, alchemy. That is: is software development alchemy or chemistry?

Software development is alchemy. Just like alchemy, software dev is not standardized, everyone has their own idiosyncratic naming systems, classifications and rules-of-thumb. Like alchemists, software engineers are often jealous of their proprietary knowledge. Just like alchemists, they are admired, feared and loathed for having secret knowledge. And just like alchemists, you have to be exceedingly brilliant to work in such a chaotic field and get anything done.

So, what changed alchemy into chemistry, and what will be the analog to that in software? Arguably the change started with notion of conservation of mass and energy, and the development of the periodic table (thanks to Lavoisier and Mendeleev, respectively). As for what that analog is for software, first we need a characterization of the field. With alchemy and chemistry both, it's essentially mixing stuff together, heating and cooling it, and seeing what happens. But what is it for software?

First, software engineering is not computer science. Computer science is a tiny subset of software engineering. In daily practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).

I'd characterize software engineering as the set of solutions to a boundary value problem[0] described as "a set of interacting screens with behaviors pleasing to humans". The current solutions to this problem have been idiosyncratically defined by resource constraints that relaxed exponentially over time[1], and characterized by elements discovered at random, by necessity: e.g. kernels, processes, files, procedures, terminals, etc. In this analysis "language" functions as a kind of "coordinate system" as in physics[2][3], within which each of these elements are described, and within which elements are combined to make new elements, which eventually yield a solution to the boundary problem (which is termed "application"). There is some coorespondence with chemistry, in that we have "elements" which combine into higher-level structures, but we lack an analogy to "conservation of mass and energy". And our elements are still highly partitioned according to coordinate system (although there have been several[4] heroic[5] attempts to unify them within a single framework.)

I don't particularly know what the standardization of software alchemy into software engineering will look like, but I'm certain that this analysis, or something similar to it, is the first steps in the right direction. Personally, I look forward to the day we can shed the considerable weight of our alchemical origins!

0 - https://en.wikipedia.org/wiki/Boundary_value_problem

1 - https://en.wikipedia.org/wiki/Moore's_law

2 - https://en.wikipedia.org/wiki/Coordinate_system

3 - https://www.rosettacode.org/wiki/Rosetta_Code - the same problem is solved in many languages. For applications: https://todomvc.com/

4 - https://en.wikipedia.org/wiki/Lambda_calculus

5 - https://en.wikipedia.org/wiki/Turing_machine