[kgrin]

"Software engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is regularly the case."

Is it though? I live in Boston, home of the notorious* Big Dig[1]. While particularly egregious, it's far from the only large-scale civil engineering project that's gone off the rails. In fact, I'd argue that until fairly recently, many more public works projects shared the "surprise factor" of software projects. I'd recommend Caro's "The Power Broker"[2] for a fascinating history of NY-area public works (among other things - great book all around), including how much of that process was about adapting the plan to new things the builders were learning along the way ("oh, turns out that soil is completely different than we planned...")

That's not to say that there aren't particular features that make software engineering its own special snowflake - as there are meaningful differences between how civil, structural, mechanical, etc. engineers operate. But spend some time in another engineering organization and you'll find it's different, but not as different as you think it is.

(And FWIW, even civil engineers sometimes follow "agile" concepts - a company I once worked for was contracted to design a highway, and even after the construction started, engineers were "embedded" with the builders to make on-the-fly adjustments based on the environmental factors they discovered throughout the process... I wish I could find their project write-up, but it was a while ago and the company has long since been gobbled up by a bigger company).

* As a (subjective) kicker, I'd add that the Big Dig, over-time and over-budget as it was, was ultimately quite worth it... much like many software projects!

[1] http://en.wikipedia.org/wiki/Big_Dig

[2] http://www.amazon.com/The-Power-Broker-Robert-Moses/dp/03947...

[iancackett]

Yep, you're right... I'm forgetting that physical engineering also suffers from some of the same problems. The thing that it adds though is a level of rigour, and ability to reason about the project, that we're still struggling with somewhat in the software world. Believe me, in 20 years since I was taught it's not strict "engineering", I've yet to see that change much, other than in safety-critical and cleanroom projects.

[StavrosK]

Engineering is much more straightforward, you have the plans and know that you need X amount of parts and Y amount of labour. Software is more like research, where you don't even know if you can solve the problem acceptably, most of the time.

[vonmoltke]

If you have the plans, it's manufacturing, not engineering.

The engineering in the design is in developing the prototypes and proving that theoretical concepts can be implemented practically. There is nothing straightforward about that, unless it is an incremental improvement to an existing implementation.

The engineering in manufacturing is about deriving ways to manufacture parts with greater yields and greater efficiency. In some cases, it is about developing manufacturing techniques that were hitherto impossible. Again, not much straightforward about this.

All of the above is rigorous, but that is not the same thing. This rigor can be applied to software development just as easily as any other product development, and when it is it becomes software engineering.

[agumonkey]

I feel it's the lack of hard laws that kill software. Unless it's a very constrained project, where limits drive your design, you'll have freedom to think about things and then it shifts into ontologies, people trying to find 'tiny theories' to express their problem in the best way. Each layer adds variability and we end up in hard to bridge technology silos.

[iancackett]

Great point!

[agumonkey]

EPR nuclear plants are suffering delays and far over budget.