Hacker News new | comments | show | ask | jobs | submit login

A while ago I had an argument with a chemical engineer about exactly this. He claimed that software engineering is an immature field and that we will eventually learn how to apply engineering principles to get more reliable programs.

When I countered that you mostly don't even know what you're modelling and that the design state space is much larger in software, he retorted that all sorts of things can go wrong with just a single pipe in a chemical plant but that it doesn't stop reliable plants from being built.

But he didn't get it: that pipe is a component in a well understood framework. It's nothing like the unexpected things you get in software. The software equivalent is that of a buggy component whose specification is well understood - if you rewrite the component, you'll get what you expect. In software, proper specification is the rub.

I have worked with many electrical and electronic engineers (I studied CS) and not one of those engineers was on average better at writing reliable software. They did try hard to specify their systems in advance, but the actual systems soon started diverging from their specifications.

I grant that the absence of evidence is not evidence of absence, but it is equally wrong to keep maintaining in full faith (and without convincing evidence) that software development is an engineering discipline.

I have never seen anyone argue convincingly for nor against the engineering approach in software. If anyone has done a study on this, I would love to read it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact