Communications of the ACM

Considering whether software engineering and engineering can share a profession.

Anonymous

Davis mentions four senses of the word "engineering", none of which qualify software engineering as an engineering discipline. A fifth sense appeared, until recently, in the Merriam-Webster dictionary: the application of science and mathematics to the design of useful things. Software engineering is not engineering in this sense, either. It could be, since mathematical logic provides principles on which useful software can be built and guaranteed to have certain behavioral properties. If software engineering were to go in this direction and the other fields of engineering adopted practices akin to present-day software engineering, the graphs would cross at some point and then diverge again. Ironically, software engineering would be going up (in my view) while the others fields descended.
- Rex Page (Univ of Oklahoma)

CACM Administrator

Like most dictionary definitions, this one seems to be over-broad. Even synthetic chemistry and architecture would count as engineering under it. Both use science and mathematics to make useful things (new chemical compounds or buildings).
--Michael Davis

Mark Laczin

It may only be tangentially related to the topic at hand, but it might be worth considering another thing that differs between the two, on the academic level:
that Software Engineers who learn the trade in college typically study in a field titled "Computer Science" - whereas a Civil Engineer would study "Civil Engineering".

Possibly just a nomenclature issue, but a lot of what people learn in Computer Science isn't really "software engineering" (to the point where some academic institutions have split their CS programs to focus on the science of computers versus the art of software design).

Rex Page

If the dictionary definition is too broad, then what passes for software engineering today fails to reside even on the fringes of engineering.

Jason Pieloor

The article seems to be assuming that (real) engineering is about physical systems and processes, whereas software is not concerned about these things, and therefore is not engineering. However I don't know of any definition of modern engineering that specifically or exclusively requires this physical world connection.

My favourite "definition" of engineering stems from an old adage about (civil) engineers, which basically states that while anyone can design a bridge over a river that will stand up in a storm, it takes an engineer to design a bridge that will only just stand up in a storm. In other words, an engineer must constantly care about the costs (i.e., money, time, resources, social, environmental, operational, etc.) involved in a project, as well as making sure the end result does what it was supposed to do. This "cost" focus is probably one reason why so many senior engineers end up in management roles - managing costs and resources is second nature. (We'll ignore the point about whether managing people is second nature as well :).

So what about software engineering as "engineering" then? I guess that may depend partly on whether you define a software engineer as an engineer by training (i.e., studied engineering at school/university) with a focus or specialisation on software, or by "mislabelling" someone who trained as a computer scientist (i.e., studied computer science), which seems to be the most common use of "software engineer" that I see/have seen in the market over the last decade or two.

Training background aside, a real software engineer, like any engineer, needs to be concerned with the costs (all of the costs) of the software in a project, as well as ensuring that the final product is fit-for-purpose. Which brings us back to the Body of Knowledge definition, and specifically to "that is, the application of engineering to software", which makes perfect sense provided you've defined what engineering is

Pradyot Sahu

We have to move forward to 21st Century with new meanings and interpretations. This may include Software Engineering as an Engineering discipline without question.

Thanks
Pradyot Sahu, 3innovate

CACM Administrator

The following letter was published in the Letters to the Editor in the January 2012 CACM (http://cacm.acm.org/magazines/2012/1/144814).
--CACM Administrator

I was confounded by the conclusion of Michael Davis's Viewpoint "Will Software Engineering Ever Be Engineering?" (Nov. 2011), mainly because anything I can do in code I can also do in digital hardware, analog hardware, fluidics, even gears and motors. One could say "Maintenance is a nightmare," but there is ample proof that software maintenance can also be a nightmare with even modest code. By drawing attention to "[m]oderate the interests of the software engineer, the employer, the client, and the users for the public good," Davis exposed an unfortunate turn of phrase that is easily misconstrued. However, the following from the ACM's own "Software Engineering Code of Ethics and Professional Practice" (version 5.2 http://www.acm.org/about/se-code) states the principle clearly: "Software engineers shall act consistent with the public interest," which also maps well to the National Society of Professional Engineers' "Code of Ethics for Engineers" (http://www.nspe.org/Ethics/CodeofEthics/index.html): "Hold paramount the safety, health, and welfare of the public."

Software engineering is not computer programming. Programming is a constructive activity, like soldering, riveting, and pouring concrete, where excellence requires special knowledge, skill, and ability. The fact that many engineers strive to be competent technicians should not confuse the issue; engineering work and technical work are simply different types of work, often done by the same person.

The overarching engineering paradigm systems engineering recruits specialty engineering disciplines, including hardware (such as electrical and mechanical), software (such as applications and embedded), and human factors (such as micro-ergonomics and macro-ergonomics). All are used, knowingly or unknowingly, in the formulation and translation of engineering requirements (design inputs) into engineering specifications (design outputs), enabling construction of systems with utilitarian and/or aesthetic value. Ideally, systems engineering occurs in a structured, systematic manner with incremental verifications and the physical realization validated against the original requirements. Haphazard design and construction may be "engineering" but is indeed unprofessional and provides no rational means for ensuring the protection of the public's safety, health, and welfare.

It may be reasonable to say developing banking and retail software systems do not require training in advanced mathematics, physics, chemistry, biology, or even social science; the same cannot be said of software systems for nuclear weapons, transportation systems, or medical devices. Designing and programming banking and retail software is, perhaps, more like bookkeeping and accounting practices and thus justifies being taught in business school. Software may be designed by engineers or by accountants, but only the former should be deemed software engineering.

The software development I have been involved in for 50 years has always required my engineering training and experience. My basic training was electrical engineering, not computer science, so, perhaps, my projects are somewhat skewed in this direction.

GM Samaras
Pueblo, CO

-------------------------------------------------

AUTHOR'S RESPONSE

Samaras responded to my quotation of Rule 1.2 of the "Software Engineering Code of Ethics" ("moderate") with a quotation from Principle 1 from the same code ("consistent with the public interest"). He then claimed Principle 1 "maps well" to the paramount clause now common in engineering codes of ethics. Not so. "Hold paramount" means put above other considerations, a somewhat higher standard than "consistent with." He also ignored most of my argument, especially on differences in curriculum between engineering proper and software engineering. His focus is solely on function.

Michael Davis
Chicago, IL