Maybe it gives us (the software builders) an excuse for failure? If it's an "art" then there's an acceptable failure percentage, unlike with "real" science.

That sad thing, I think, is that although software development should be like traditional engineering, usually it isn't. Failure is acceptable, even expected - "To err is human, but to really f%^k up takes a computer". Time and again I see projects with inadequate specification, unclear goals, unrealistic budget, etc. and I think 'This isn't how you'd build an aeroplane'.

I guess it's a question of consequences. If a server falls over, you restart it. If a plane falls from the sky, it's a big deal. So planes are expensive, and don't crash very often, and servers aren't, and do.

I read Richard Feynman's "Personal observations on the reliability of the shuttle" and the thing that really struck me was how he actually praised the quality of the Shuttle's software. And it seems to me that they achieved this by treating the software exactly like an engineering discipline, and accepting that this adds time, effort and cost. Sadly, most companies will not accept this. Sure, they might say they want 99.99% reliability, but you try getting them to pay for it. The difference is, NASA can't afford failure.

Thus, for most customers, except maybe parts of the government and military, engineering rigor and process goes out the window in favour of 'hacking' together a solution.

"Writing and maintaining software are not engineering activities. So it's not clear why we call software development software engineering."

Let's paraphrase a bit.

Welding metal and bolting beams are not engineering activities, so it's not clear why we call construction civll engineering.

Well, duh, it's not. But just as above, deciding how good the bond has to be and what kind of I-beam to use (even though you can weld and bolt without being on an engineering project) is engineering, so are the processes mentioned above.

So there.

This is discouraging, but not surprising. I often find even software 'engineers' that don't treat their jobs as a serious discipline. There are probably more software hacks than software engineers out there. It goes without saying, to those of us who know, that software development benefits greatly from the best practices of other engineering disciplines. But too many of our brethren ignore these best practices. And that is part of the perception problem.

I would like to quote Wikipedia. On the first line under the subject Engineering:

"Engineering is the design, analysis, and/or construction of works for practical purposes."

Sounds like software engineering would fall into that category.

Eric Wise has counterpoints on

codebetter.com/.../rejecting-software-engineering.aspx

I think that Software Engineering is a real engineering discipline, however it is an immature discipline. We are only just beginning to name the essential inventions in software and build standard interfaces to them.

Our experience in software so far has been Computer Science. We have been experimenting with ways to interact with and program a machine. We have been trying to understand the effect of algorithms and figure out what the natural level of complexity is in our work. A mature engineering discipline requires more than this.

I think the defining difference between a mature engineering profession and the current state of our software engineering is a lack of components. Drafting a bridge or a printed circuit board is a design process. However, the design is based on known parts. We know the stresses a particular I-Beam can take. We can order 1000 of them and build the properties of our bridge apon them. We can order specific chips and assemble them into a product on our circuit board. These boards can themselves be manufactured en masse. Their properties can be determined and bigger systems can be built around them.

Software projects still seem to involve much more invention of components than composition of components. I suspect that many more domain-specific components need to be available for assembly alongside more general components. General components such as "database" or "web server" can only take us so far. We also need more "power consumption predictors", "automatic train routers", "voip telephony endpoints", etc. We are only just starting to name these things. We are only beginning to build the social, legal, and technical standards  that would allow us to reliably and predictably engineer systems from them.

Benjamin

I share you opinion, but wanna add, that sometimes we loose the real meaning of the word and give it another one.