I like why it is important to you. Engineering is the only why to give an application a future.

I wrote a small blog on what I see the difference between .net software development and software engineering is.

[http://realworldsa.dotnetdevelopersjournal.com/net_software_engineering_versus_net_software_development.htm]

For some reason te link to the blog didn't go through. Trying again..
http://realworldsa.dotnetdevelopersjournal.com/net_software_engineering_versus_net_software_development.htm

Well I think it is a branch of engineering in certain circles. When I worked an electronic engineer the software we wrote to program our PLCs (PROGRAMMABLE LOGIC CONTROLLERS) was engineered just like the components that went in to the hardware.

In the domain of applications built for computers (web apps, windows apps, enterprise apps) I know it is possible to do, but is for the most part rejected by organizations building the software. I think it is mostly because a lot of them have been introduced to building applications with tools like VB 6.0, and other IDEs that promote RAD development. Which is a good thing when considering time to market, but a bad thing for maintainability, quality, and building applications that actually meet the requirements of the client. It is basically building an application that is a legacy application the day it is released. By legacy I mean you don't know how it was built, so it will be difficult to modify, maintain, debug, and upgrade.

I know Rational was striving to get us there, but now they are no longer around. They have been swallowed by IBM, so I don't depend on them as a resource for what one might call open software engineering. Meaning no one is influencing their goals of improving software engineering.

Currently I review many organizations to extract from them what might be good practices for software engineering. Microsoft, IBM, Sun, Intel, and all those competing in the market. But I am always wary and need to make sure what they are preaching/teaching is not for their own hidden agenda that is market focused. I include all the open source projects in this group also. I always like to do what Microsoft and these other groups do internally, but I find a lot times I avoid doing what they are telling the market to do.

I trust a few sources without hesitation and they are the Carnegie Mellon Software Engineering Institute (SEI), Massachusetts Institute of Technology (MIT), and Institute of Electrical and Electronics Engineers (IEEE).

It is being done is some circles, so I would say that qualifies it as a branch of engineering. It just isn't being done nearly enough.

Engineering needs a process. I talk about that here: http://realworldsa.dotnetdevelop ersjournal.com/the_process_ladder_up_rup_eup_ple__ never_neverland.htm

Your base is this:
If we took as premise that all engineering is applied factual science (unlike formal sciences -of which there are no applications for the very reason they are formal), and the sine qua non attribute for a science to exist is that it is made of theories; and each theory is a system of laws; and each law is a general, necessary and constant relationship between phenomena (observed facts); and the observed facts can be perceived with the senses and repeatable…

The process (UP, RUP, and so on) defines the laws. The laws are what keep the humans in the process repeating actions that provide a predictable outcome.

The same way a process defines how an engineer builds an electronic component. The laws of software engineering are govern by the laws of electronic engineering. Combined they create computer science.

The book CODE by Charles Petzold is a cool read that walks across that bridge.

Who knows, maybe you got a point and we are all living in the Matrix, and I am really just Mr. Anderson thinking a am a software engineer…

But aren't the bits being placed into the atoms constrained by the laws that the atoms are enforcing? And the atoms are being placed together by the laws that nature allows us to structure them. To me the laws are being forced upon the next layer of abstraction - the chip's physical structure -> the electronic storage into the chip -> the bits arranged to form digital communication patterns that move through the layers of language abstraction for assembler to C to IL to C#.

These two links provide some interesting perspectives on the point you are raising.

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Software_Craftsmanship

The second says this about the topic:

While software engineering appropriately describes the processes necessary to build large, complex systems like those at work doing tasks like flying the Space Shuttle, software craftsmanship as modelled after the guild tradition in the building trades is in fact how the bulk of software is actually written.

Which I would agree with.

My final post on this is here:

http://realworldsa.dotnetdevelopersjournal.com/net_software_engineering_versus_net_software_development.htm

At macro level it may be termed something other than engineering....

This is a well-made analysis of the question, which is commendable when so few others are as careful. I think I can answer in reasonable way.

Looking one step further, we may ask: what is it that enables scientific laws to be formed? It is a basic material that is substantially determinate -- that behaves sufficiently 'regularly' as to be amenable to logical, mathematical models being made of it.

Does software have such a material? Yes. Looking at the very lowest level, there is the bit with its properties of identity and mutability. It is necessarily entirely determinate -- it is in a sense made of the same stuff as a model itself. Now, although this medium is clearly adequate for laws, does it have any? Algorithmic complexity results must count -- e.g. comparison sorts having minimum O(n log n). They are substantial, useful, and measurable. Yet there still seems a lack of such solid laws generally.

So software certainly has a core of the type of an engineering, it has the potential, but it has not been fully realised. Software seems best described as an immature engineering -- something often felt, but the above gives a rational account of why.

For more, see:

http://www.hxa.name/articles/content/building-model-for-software_hxa7241_2009.html

http://www.hxa.name/articles/content/software-engineering-and-civil-engineering_hxa7241_2008.html