The way I look at it, software 'engineering' is an apt term. When you look at, say, a suspension bridge, you can tell how it works in principle. But you also wa

The way I look at it, software 'engineering' is an apt term. When you look at, say, a suspension bridge, you can tell how it works in principle. But you also want to be confident of the standards to which it's engineered: that the bolts wont slip out, that the surfaces have been coated properly, that the stress factors have been calculated, that the blueprints are up to date, that the right metals were used, the right joints, etc. etc.. All the details which you don't care to understand but know that professionals have taken care of them. That's how I think of software engineering - applying all the tools of the trade, like unit testing, Big-O analysis, compatibility handling - ideas that are not central to any one implementation but common to all projects. Stuff you don't write about in the tour guide, but is pretty darn important all the same. Some of it industry standard practice, some of it unsung heroics. (note: not that I think normal construction is comparable to software development. In a nutshell any computer system has an orders of magnitude more 'moving parts' (even if they only exist in the abstract) than any normal object or machine. Most programs are built on layer upon layer of supporting frameworks right down to the hardware. When you're at the top, things are inherently unstable)