[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!