Alan Kay has been giving talks on this for some time. He says there is no equivalent of the arch of civil engineering in software development, which is at the architectural equivalent of the pyramids. Analogies like this are difficult to sustain, but one might argue that civil engineering has a head start over software engineering by a couple thousand years. Others might protest that macros and algorithms have been around at least as long. I think this misses Alan Kay's point that the Empire State Building took 3000 workers 500 or so days to build, and those kinds of coordinated efforts are unheard of in single software engineering projects. One could counter that many large programming incorporate the work of thousands of others in the form of algorithms, techniques and standards, but civil engineering is no different with respect to accumulated wisdom--over a somewhat longer period. Civil engineering does provide for coordinated efforts among thousands of construction workers on a single project.

Here's where the analogy falls apart - civil engineering does not provide for coordinated efforts among thousands of construction workers. Construction management does. Any large building project will involve a civil or structural engineering firm, which designs the building or structure, and a construction firm, which builds it.

The construction firm is your compiler toolchain. The benchmark to meet is how long it took to design the Empire State Building, not how long it took to put it together.

Where would construction management be without civil engineering? The analogy between construction firms and compiler toolchains is either laughable or serious publishable research--I've never seen it mentioned once in the civil engineering literature.

Civil engineers are self-confident and don't go comparing themselves to all the other engineering disciplines trying to convince themselves they are real engineers. Software engineering is prone to a significant minority of people who are not so self-confident.

Personally, I am. In my opinion, whenever someone tries to drag in a methodology from other engineering disciplines they do so with a blinding ignorance of "cost" side of the cost/benefit ratio (and often non-trivial ignorance on the "benefit" side too), and the real differences between software and physical things. If car engineers could smash a car into a wall, observe something they didn't like, tweak something and 30 seconds be smashing another car into a wall effectively for free, their design methodology would be different too. (And if you feel inclined to get into a really detailed argument about how it would affect them because you think I'm assuming something about exactly how it would be different, you're missing my point, which is simply that it would indeed be different. Especially towards the beginning phases of the design.)