Link Details

For those still not convinced. This article by Jack Reeves very eloquently expresses the big picture:
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign
The big deal is that 'Software Engineering' is really a design process not an engineering process.

Please let me move to whatever planet you're living on, because the physics here on Earth bite me in the butt every time that I write an inefficient piece of code. I tried to parse a 50k line text file the other day and it ground my system to a halt... man, I bet on a planet where software didn't obey the laws of physics, it would get done instantly! How awesome is that?!?

kenman you need to approach this with an open mind. When you picked an inefficent algorithm to parse that text file it was a poor design decision not a poor engineering decision. You can perform algorithm analysis and find out the performance of your algorithm in terms of space and time but the overall decision of which algorithm to use based on the needs of your application is actually a DESIGN decision. As the link from Jack I provided points out we are SIMILAR to engineers but not quite the same.
When an engineer starts out on a project he begins with a design and then since design is an iterative process he repeats this design process over and over again until he is satisfied it is correct. Then at the final stage he performs a mathematical analysis usually to confirm the correctness of his design. A software developer follows the first step precisely like a traditional engineer would. However, it is the final step where the differences begin we lack a practical mathematical analysis step to prove the correctness of our programs.
Lets take the Windows XP OS for example according to Wikipedia: http://en.wikipedia.org/wiki/Source_lines_of_code it has around 40 million lines of code. One way we can analyze the correctness of the program is to test the logic of conditional branches in the code to ensure correctness. Lets make an extremely conservative estimate of the number of if statements(a form of conditonal branch) that are present say 5 million. For every if statement there are 2 possible code paths. So based on this you would have to analyze 2**5,000,000 different possible code paths to ensure logical correctness. Since this isn't really feasible or economically sound we use the build and test cycle instead to prove correctness.Which really isn't mathematically precise so we have to use heuristics or a design process as we observe the results of the test and build cycle.
Another thing is the requirements of the user and their criteria for correctness which is picky and fickle. One user may be frustrated and complain that Windows XP takes 5 seconds to report a file is in use and deny the delete request while another user may be just fine with that. How do you mathematically analze a user you don't you use heuristics and a design that meets the needs of the user instead. It is this lack of mathematical rigor that keeps us from knowing truly what a good software design is so we must treat it as a craft or design in order to continue to develop software for the users who shall consume it.
,

Looks like definition of Engineering needs changing