> Engineering components exist in the real world
Yes, and computers don't exist in some alternate dimension. People might forget it sometimes, but if you're a real engineer, you should know how a computer works, and know it's not magic, it's physics that make you're computer work. Software is merely an abstraction. Secondly, math is also engineering, but you can't touch it, can you?
> Engineering components interact in more predictable ways
No, wrong again. Software is perfectly predictable (BTW, if you want, you could build a mathematical model of every program. 100% predictable). If you make mistakes in other engineering branches you can get some strange results too.
> Engineering has fewer fundamental midcourse design changes
I don't see the link between engineering and design changes here. Are you trying to say that no single engineering project changes during it's life? Just look at prototypes of cars, those changes are quite massive. Secondly, ask yourself this question: How much does it cost to change a rocket design midway compared to a software program?
> Is software development a science?
Well, that's the point, in my opinion it's engineering.
> Writing software is more an art than an engineering discipline
Some think so, but really, it should be seen as engineering. Why? Artists make choices related to what they like, how they feel. Engineers make objective choices (or at least they should, nobody is perfect).
Full article here: http://www.paulgraham.com/knuth.html
This is a discussion about meaning of words, so appeal to authority finishes the argument :)
No, you can't - and provably so. (http://en.wikipedia.org/wiki/Halting_problem)
Even in the real world, you have user interaction - and their usage of your software isn't predictable, even if your code mostly is. Your codebase might be totally rock-solid, but users have a way of rapidly demonstrating that your assumptions were totally off-base.
There is some art, and some engineering, but the essence of programming is design. Every decision has costs and benefits. Design decisions aren't right or wrong in the abstract, you're simply trading off one thing for another - (Memory vs. CPU, CAP, etc).
The key is figuring out which benefits and which costs are most suitable for what you're developing - or more accurately, how the software will actually be used (not necessarily the same thing).
Have you ever tried to do this? Once you get past fibonacci functions, the amount of time and effort required is measured in PhD-man-years. And even then, all you have done is moved the risk from the code to the proof, because when you work on something that large, the risk that the model does not represent reality (either due to oversight, lack of understanding, or not correctly capturing the interplay between two aspects) becomes an issue.
The issue is that the state space for software is so much larger than the state space for bridge building that we just don't have the tools to effectively model and predict yet. I won't argue that software is somehow an art, because I'm hopeful that someday we will have those tools, but I will argue that it's not engineering yet. The Alan Kay quote about pyramids in the article hit it spot on. We are still piling blocks on each other and hoping it works at this point.
>String theory, the most promising method of modeling quantum physics
Still a bit controversial to make that claim, isn't it?