And about “not using real physics”, so what? Chemical engineers don’t usually use any real physics either, but they certainly use real chemistry. Are they any less engineers for that? Well, software engineers use real computer science.
Yes, that’s a good point. My response was overly simplistic.
When Mark Zuckerberg wrote thefacebook.com as a simple php/mysql app, he was definitely acting as a developer (more than a programmer) but not yet an engineer. However, I imagine fairly quickly thereafter as Facebook scaled, it became a project that required actual engineering. I’m not sure where that line is, I just know which side of it I’m on 
Basically, if terms like “engineer” or “architect” weren’t re-purposed to apply to software people by analogy, a new word would have to be created to describe the job that is “software related, but higher level than just ‘coder’ or ‘developer’”.
Not really. Software engineering embodies most if not all the common professional elements of all the traditional engineering disciplines. Indeed it has fed back into them. Whilst the nascent software engineering discipline went to the traditional areas to find tools and processes to help with managing the problems, it soon started to develop its own, and many of them have been taken up by the traditional areas as their problems became more difficult to manage.
Architect is a looser term, as architecture as practised is a curious melange of art, craft, and engineering, with different practitioners having quite different balances between them. I would be happy for software-architect as a professional name to vanish, but software engineer is quite solid.
You misread what I wrote. I’m not saying there should be a new word to replace “engineer” as it applies to software. Just if we were to abandon the term (and “architect”), we would need to new vocabulary to describe the job. (I.e. it’s not just a regular coding job dressed up to sound fancy by attaching a fancy word).
Actually, a lot of what many chemical engineers do is what we would term “process engineering”, i.e. ensuring that mixing rates and temperatures are controlled, that pumps and piping are clear and operating at expected pressure and flow rates, assure that a system is running within control margins, et cetera, so there is a lot of practical “nuts and bolts” type work there. Actually, I’ve known several chemical engineers who write control code almost exclusively, doing the work that would largely be considered to be within the discipline of software engineering.
As far as accreditation, while there are certain fields such as civil and architectural engineering where having a PE license is mandatory (at least at a project engineer/manager level) to sign off on drawings and specifications, the vast majority of working engineers don’t have a PE or are even eligible to apply to take the exam, as you have to have worked under another PE for some duration of time (depends on the state). In some states you have to have a PE in order to market providing “engineering services”, but as long as a company has a PE on staff who nominally oversees engineering work in some capacity (not necessarily as a manager) the company as a whole can perform engineering design and analysis. In general, excepting civil/structural engineering for public buildings and works, the engineering profession lacks legal certification akin to bar or medical licensing, certified accounting, et cetera, largely because the types of work that “engineers” do is so diverse that not one exam could really encompass all different types of skills used.
As for the value of viewing software developing in an engineering context, there is a tendency over the last couple of decades to “solve the problem in software”, i.e. when dealing with development problems with hardware systems to use software control to compensate. This means that software cannot be viewed as a separate, independent system of instructions but a key part of any complex system that is critical to reliable operation. It also means that software picks up the slack to meet schedule when testing reveals a problem with hardware that can’t be easily fixed. In that schema, software is definitely part of the engineering and software engineers have to understand the physics of how a system works, at least insofar as software commands interact with the physical system.
As an example, when I was working on a controls lab project in school we were presented with a programmable logic controller (PLC) which ran an articulating arm that translated and rotated to pick up a block. The PLC system was designed (intentionally) to have am undocumented latency in feedback control such that if you just ran the relay ladder logic (RLL) code as written, which theoretically should have picked up the block and delivered it to the goal, the feedback control would fail to fully grasp the block before raising and the system wouldn’t work. To solve the problem you had to figure out the correct timing sequence to get good engagement and manipulate the block to the goal within the system timing requirement. In order to solve the problem we had to develop a logic flow, diagnose where the latency occurred, figure out how to modify the feedback and timing sequence in order to assure engagement without excess delay, and execute the program. All of this required defining and flowing requirements to the component level, (simple) control system modeling of the lag-lead effect, regression testing, and writing code in order to resolve the problem. This is software engineering.
Stranger
Indeed. 
I need some sleep. 
Well, no, it wasn’t.
You know I’m just realising that is in fact the case. More like I just found there was a little way in which the universe seemed disordered. But I’m pretty much in a state of acceptance now.
Stranger’s right. If software engineers don’t exist, then most engineers in other fields need to drop their titles and just call themselves “electrical circuit guys” and “mechanical gear mouseclicker designer guys”.
The confusion I feel is that the average guy in a coding sweatshop spewing out barely functional java code for some bloated app that buggily implements some vast wishlist of features that grows every time the customer is communicated with…is probably not a software engineer. He can call himself that, just like an electrician who wires houses can call themselves an electrical engineer, but both people are misrepresenting their role and skills.
His stuff may work well enough to make money, but it’s a mess internally and will endlessly have critical flaws and need monthly security updates. It will be sluggish and unpredictable to use the software. It will fail unexpectedly at times. Kind of how a rube goldberg machine is not the product a mechanical engineer will stand by.
You were listening in the wrong places. Computer Magazine had a special issue on Firmware Engineering in 1978, which title was chosen as an extension of software engineering. I had a paper in it and my adviser edited that issue.
IEEE Transactions on Software Engineering was established in 1975.
Here is the story, from someone who was a CS PhD student at the time. In the early '70s it became obvious that we didn’t really know how to write reliable software on time. I got a set of articles on software disasters as an undergrad. This was the beginning of the structured programming revolution, started off in part by Dijkstra’s famous letter on Gotos Considered Harmful. Computing Surveys had a special issue on programming - actually structured programming, in Dec. 1974, with articles by Wirth, Knuth and Kernighan and Plauger. A look through it shows no mention of “software engineering.” I know from the paper I had in this great journal that there is a long writing/reviewing/publication period, so these papers were probably written in late '73 or very early '74.
At the time we were very aware that hardware engineers seemed able to create minicomputers and mainframes more or less on schedule without them falling apart. Software engineering as a term was adopted to try to convince people to use similar practices as the hardware engineers, and stop writing software willy-nilly. The way I taught programming in 1975 was very different from how I was taught programming in 1970 - and how I taught myself programming in 1968.
BTW, today I work with real hardware engineers (microprocessor designers and verifiers) and good programming practices are as rigorous as hardware design practices.
Probably moreso; modern software is such a complex system, and failures are so non-intuitive to find, that the only way to produce reliable and robust systems is by applying rigorous engineering principles and disciplined processes.
Stranger
Google Ngrams suggests that “software engineering” became a very common term in books in the 1980s, surpassing “computer programming” by 1987 or so (and since uses in books probably lag use in the field by several years, I’m not surprised that there was a journal on software engineering in 1976)
And, as such, the term “software engineer” as it was understood in say… the mid 1990s is kind of misleading in this day and age. By that, I mean that software engineering is a term describing the application of engineering principles and practices to software development. Typically this is done in relatively large teams- you have analysts, designers/architects, managers, testers, QA people, coders, all of which are integral to the software engineering process. The coders themselves are just the production end of the colossus- they build the parts that the designers and analysts have specified.
In a sense, the coders themselves are more akin to machinists or mechanical assemblers if we’re comparing to something like an aircraft design & manufacturing project, and the actual “engineers” are the guys who design and specify the software- some combination of the analysts who devise the requirements, and the software designers who translate that into a system design.
Software engineering isn’t just the ability to write structured code; that really falls under the category of “competent”, like having a carpenter who can nail things accurately, or make accurate cuts.
Nor did they ever.
Trains have always been driven by train drivers.
It has always bugged me when a grease monkey in overalls has the temerity to describe himself as an “engineer”.
He isn’t. He is either an “engineering worker”, a “machine operator” or a “mechanic”. All of which can be highly skilled jobs.
But an “engineer” he ain’t.
Maybe so, but hardware people don’t get to send out updates every two weeks.
I’ve seen a talk from Microsoft about software test and verification. Good, but for hardware we throw random instruction sequences at the simulation model of the processor for months, using thousands of processors. And most of the problems I’ve seen in silicon are not logic bugs but weird process interactions. It used to be that hardware was easier than software because things happening on this side of the chip didn’t affect the other side unless there were signals between them, but with power droop and other such stuff that is no longer true.
I believe that. By the time something gets into a book, everyone already knows it, and by then lots of programmers were elevating themselves into software engineers.
Perhaps to try to get as much respect as sanitation engineers. 
Yeah, I was tired and couldn’t read. Sorry.
That’s true about architecture, but software architecture is nevertheless a distinct discipline, whether one regards it as a specialty within software engineering or a separate field. The distinction is basically that architecture is at a higher level of abstraction – software engineers design and build specific systems, while architects are more concerned with their general structures and design principles. Somewhat like traditional architects are concerned with both the form and function of buildings, and design them to accommodate how people live and work, while structural engineers make sure they’re built so they don’t fall down.
Software architecture is most relevant to very complex systems and especially to distributed systems. Indeed it can be broadly defined as the first level of abstraction used to deal with issues of software complexity. An example of software architecture would be specifying standards and methodologies for using middleware either to build distributed systems or to integrate existing systems so they can share business information. Or specifying how systems should be built to achieve a given level of availability and fault tolerance. What would you call someone with that job function if you didn’t have “architect” in the vocabulary?