When I actually get some free time and surf around the blogosphere I often see people referring to software as "engineering". I've always had a problem with this term because it implies things about software development that simply are not. Let's take a look at Dictionary.com for a moment. re: engineering
the art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants.
So here's where the whole software engineering thing falls down for me. Building software is not like building a bridge. It's just not. In physical, "real world" engineering you have the laws of physics, near perfect information on durability, composition, balance, etc. A programmer, as Fred Brooks puts it (The Mythical Man Month) is like a "poet who works only slightly removed from pure thought-stuff". There is a plethora of languages and methods for achieving the same results in software development and none of them are exactly the same. For something to be labeled as an engineering science in my opinion, it needs to have known values and be infinitely repeatable. Software development meets neither of these.
Part of the issue is that programming systems are defined by the user's needs, which are infinitely varied across companies. Once you step out of standard software packages and into the custom code world, every system is completely unique and is shaped by the users and by the individual humans working on the project. This is one of the joys of working in software in my experience, since even problems that are similar to ones you've solved before can add new twists and features, keeping the work fresh and challenging. At the same time though, this is what prevents me from referring to software development as engineering, because there is no silver bullet, no common standard or schema for doing things. We are artists that are really good at math and logic.
Look at the estimation problems we have in software. How many of you out there can truly, honestly, to the day pick out when you will be finished with a software project? The bigger the project, the rarer this ability is. Sure you can fudge your numbers and add padding so you can be reasonably sure you won't be late, but calling your complete date agressively is near impossible in large projects with many team members simply because you are working with thought-stuff and unlike building a bridge, you can't pull a template from the last 40 bridges you've built and nail down a relative time line. Additionally, the human factor kicks in on large projects. It has been well noted by researchers like Sackman, Grant, and Erikson that "very good professional programmers are 10 times as productive as poor ones". This is also unlike building a building where the variance in productivity between say, people putting up drywall is far less than 10 times. If software development was more like engineering you'd be able to walk in and say "oh, you want an invoice billing system, that'll take 500 hours" and you'd hit that target nearly every time. This is far from reality.
Additionally, unlike in engineering where you want a free flow of information, I agree with David Parnas, who asserts that the various modules of code should be encapsulated with well defined interfaces, and that your programmers should be shielded from the reasoning, code, etc behind modules that they do not directly own. I actually learned this the hard way at some past companies where developers across teams and modules got access to all project documents. This lead to a lot of infighting where developers would cross team boundaries and try to impose their biases and design preferences upon other teams which was horrible for productivity. The technique exposed by Parnas also lends itself better to separating your application into conceptual chunks, which makes it much easier to manage and parallel develop.
Regardless, my end point is that I don't think software development will ever be able to be defined as engineering in the traditional sense, and being that a company's use of software technology can lead to huge competitive advantages I really don't think we ever want it to be.