This is exactly backwards. The answer is:
blueprint:building :: code:software
Failure to understand this is the reason why most comparisons between software and engineering are, as the author has correctly identified, nonsense.
He is unable to recognise this error due to a lack of experience with engineering, as evidenced by this statement:
If my grandfather had responded "It depends" to a question about how to produce a 1-ton spool of 2mm-thick copper strip, he'd have been fired on the spot.
To a first-order approximation "It depends" is the best answer to any engineering question, not just any software engineering question; the author's grandfather may well have agreed with this. Don't get me started on the footnote.
If the author wishes to actually learn something about engineering instead of just repeating erroneous clichés about it, I would recommend he start by reading anything by Henry Petroski.
I stand by the blueprint:building :: X:code concept. Brian posted a comment on the actual post along the same lines as your rebuttal:
"With regard to "blueprint:building :: X:code", I think code is the blueprint. If not code, then a specification that's precise enough that it may as well be code."
And I'll repeat here that if precise specifications required code, then you wouldn't have regexes, SQL, or any of the other common (and uncommon) DSLs that flit about. If you think those things are code, then what about BNF grammars? RDF triples that inform expert systems? There are a lot of things that system behaviour that don't suffer from the problems of software as I described, and they often are far closer to the relevant domain than any "code" that would be required to implement the desired behaviour directly.
The problem with this theory is that it relies on what I've seen best expressed as "the neat separability of ends and means." This is also the fundamental principle of top-down design, and it's the reason people hire armies of (<cough>Java<cough>) programmers, give them no domain knowledge and ask them to construct the code while waffling about how projects are like houses.
In the real world that's simply not true. Engineering is where ends and means meet and overlap and are reconciled through the process of design. The result is, for civil engineers, blueprints; for software engineers, code. That's why I think you have code on the wrong side of the relation: because code embodies both ends and means it cannot be merely constructed, it must be designed.
The thing is, so much of what software developers do could be systematized, or at least codified into what would often manifest as what we'd call "tools" that are then used to far more productive effect by those domain experts.
I've mentioned Matlab and Mathematica elsewhere as an example of delivering domain-specific notation, but they're also a great widespread example of delivering a domain-appropriate environment. What if these tools didn't exist, and any time someone needed to do some math, they had to cajole some programmers somewhere to help them get the job done? That'd be a disaster in relative terms, but that's the status quo of so many other "domains" where software development is regularly involved.
Is this article really just a call for the splitting of Turing-complete languages into software "materials", a group of DSLs that provide constraints? Programming in universal languages would become like materials science or industrial R+D.
Associating general-purpose programming languages with materials science seems reasonable. Building the systems that are used to build systems, etc.
Though DSLs are the most common manifestation of declarative, often constraint-based directives, thinking about all such things as text-based is another blind assumption made by most. Far higher-bandwidth "interfaces" for defining systems will simply be necessary in so many fields that suffer under the yoke of mostly-ASCII text. Just look at mathematics and e.g. Matlab and Mathematica for a super-simple example. More broadly, data, design, and process visualization continues to be a growing "trend" (more like an inevitability, but whatever) -- why shouldn't those visualizations function as the model for the relevant domain experts (whereas they are so often simply presentational)? The sooner they make that transition, the better.