Communications of the ACM
Computing ethics
Will Software Engineering Ever Be Engineering?
Credit: Hank Osuna
An anonymously attributed adage states: "With another name, social engineering would not be mistaken for engineering." Approximately 15 years ago, I published a short article in the Journal of Engineering Education arguingamong other thingsthat software engineering was not then engineering.1 I have now been asked whether enough has changed to make me think software engineering is engineering. My answer is: much has changedwith some changes weakening the separation between engineering and software engineering and some reinforcing itbut, overall, the argument stands. This answer will surprise those who, unaware of that article, think software engineering's status as engineering is obvious. I therefore think it wise to precede any explanation of why software engineering is not engineering by disposing of a few unexamined presumptions that might make software engineering's status as engineering seem obvious.
Senses of Engineering
"Engineering" has at least four senses in English. One, the oldest, understands engineering as tending engines (originally, "engines of war"). Casey Jones was an engineer in this sense; so is the custodian of my building, a licensed "boiler engineer"; and so too, the sailor rated "marine engineer." Neither engineers (strictly speaking) nor software engineers are engineers in this sense.
The Software Engineering Code of Ethics and Professional Practice differs in significant ways from all the engineering codes I know.
Almost the opposite of this first sense is what we might call the functional sense, engineering-as-invention-of-useful-objects. In this sense, the first engineer may have been the caveman (or cavewoman) who invented the club, cutting stone, or fire pit. Though this sense would certainly make software engineers engineers, there are at least two reasons to reject it here. First, the functional sense is too broad. Architects, industrial designers, and even weekend inventors are all engineers in this sense, making software engineering's claim to be engineering uninteresting. Second, the functional sense is anachronistic. It takes a sense of "engineering" that did not exist much before 1700 and applies it to cavemen, carpenters, tinkerers, and the like, who would have understood themselves quite differently.
The functional sense of engineering nonetheless seems relevant here. Software engineering's official Body of Knowledge offers this definition of software engineering: "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software."2 The Body of Knowledge assumes, without argument (a mere "that is"), that engineering is a certain function, any "systematic, disciplined, quantifiable approach to the development, operation, and maintenance [of something]". That assumption must be false. It would force us, for example, to rank accountinga field no one supposes to be engineeringas "financial-records engineering" (since accounting is a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of financial records).
Closer to our subject is a third sense, engineering-as-discipline. A discipline is a distinctive way of carrying on an activity, some combination of knowledge, skill, and judgment that must be learned. Any craft or trade has its disciplineas do many activities that are not craft or trade, such as meditation or calisthenics. In this sense, neither architects, nor industrial designers, nor weekend inventors are engineers. Architecture and industrial design each have a discipline easily distinguished from engineering's. Weekend inventors have no discipline at all; they may invent any way they like.
Software engineering is not engineering in this third sense. The body of knowledge engineers are supposed to learn differs in important ways from software engineering's body of knowledge. So, for example, engineers have to take courses concerned with the material world, such as chemistry and statistics; software engineers do not. Software engineering's official Body of Knowledge was in fact an important step in clarifying the distinction between engineering proper and software engineering. It requires software engineers to know things other engineers do not and not to know some things other engineers do know.
Software engineering has, indeed, become a profession. What it has not become is part of the engineering profession.
The last sense of engineering we need to distinguish here is engineering-as-profession. A profession is (we may say) a number of individuals in the same occupation voluntarily organized to earn a living by openly serving a moral ideal in a morally permissible way beyond what law, market, morality, and public opinion would otherwise require.a An occupation is a discipline by which one may, and some do, earn a living. Both engineering and software engineering are now occupations but, having (as just noted) different disciplines, must be different occupations. That is one reason why they cannot share a profession. There is another.
The Software Engineering Code of Ethics and Professional Practice differs in significant ways from all the engineering codes I know. Software engineers are, for example, supposed to "[m]oderate the interests of the software engineer, the employer, the client and the users with the public good" (1.02).b Engineers do not now have such a duty to moderate.
Software engineering has, indeed, become a profession. What it has not become is part of the engineering profession. Anyone who claims otherwise must find a sense of engineering different from those distinguished here, one that makes software engineering a part of engineering without including as well disciplines, occupations, or professions, such as architecture or accounting, that clearly are not part of engineering.
Professions are voluntary associations. You cannot become a member simply by claiming to be one. You must be admitted (by the profession, not just by a technical society like the ACM). Engineering has a long history of other occupations claiming to be engineering: recent examples include genetic engineering (a kind of tinkering with genes); reengineering (a fad in management); and financial engineering (gambling on Wall Street). Software engineering actually began with an attempt to copy engineering practices, making its claim to be engineering more respectable than most. But the enormous complexity of software has forced software engineering to develop in ways engineering has notand may never.c Many of the very methods that make software engineering useful distinguish it from engineering. Engineers have good reason to continue to treat software engineers as belonging to another profession.d
I have, I hope, just explained why I still think software engineering is not engineering in a way that engineers should recognize. I now want to point out four reasons to think that engineering might someday merge with software engineering. All four are, oddly, changes in engineering, not software engineering.
- Electrical and computer engineering (ECE) is often thought to be the field of engineering closest to software engineering. Over the last decade, ECE has become less committed to traditional engineering courses concerned with the material world. So, for example, a number of ECE departments, including the one at the University of Illinois at Urbana-Champaign, have stopped requiring statics, dynamics, and thermodynamics. If that trend continues, then either ECE will split off from the main body of engineering or engineering's core of required engineering courses will increasingly resemble software engineering's.
- Since the 1700s, engineers have had to know just two natural sciences: physics and chemistry. Recently, some programs in environmental engineering, biomedical engineering, and agricultural engineering have begun to allow students to substitute biology for physics or chemistry. For engineers, this makes sense, since several of the new frontiers of engineering rely on biology rather than physics and chemistry (as until recently). But, if this trend continues, engineering's science core will increasingly resemble the science courses software engineers take to satisfy general distribution requirements.
- Engineers are increasingly replacing mechanical systems with software. Not only do most engineers now use software regularly, many write specifications for software, modify existing programs themselves, or even write (simple) programs. Whether or not software engineers do any engineering, engineers increasingly engage in activities that look like software engineering (even if these engineers do not call themselves "software engineers" and do not work the way that software engineers would). Whether some fields of engineering will dissolve into software engineering seems an open question.
- Computer science used to have an accreditation body separate from engineering's. That is no longer true. All computer science programs, including software engineering, are now under engineering's accreditation body, ABET. Of course, the accreditation process and standards distinguish between engineering programs and computer science programs. But that distinction does not preclude eventual merger. ABET has always distinguished between various fields (or subdisciplines) of engineering. So, for example, it always sent mechanical engineers to review a mechanical engineering program; electrical engineers, to review an electrical engineering program; and so on. The expansion of ABET's accreditation powers makes it easier than before for software engineering to merge into engineering, indeed, for all of computer science to do that.
Whether or not software engineers do any engineering, engineers increasingly engage in activities that look like software engineering.
Having pointed out four reasons that seem to point to software engineering's eventual merger with engineering, I now point out three reasons to believe the merger will not happen soon, if at all:
- All engineering is still fundamentally about physical systems; software engineering is not. Even a field so closely allied to software engineering as computer engineering must take into account physical factors in design, for example, heat produced in a microchip or speed of electrical current, to a degree software engineers do not.
- Software engineering is today a large profession, indeed, one of the largesthalf the size of engineering, true, but about the same size as medicine or law. With so many practitioners, software engineering is more likely to divide than to join up with another large profession.
- If computer science ever ceased to be the home of software engineering, the most likely new home might well be management information systems or information technology management. These business disciplines resemble software engineering at least as much as engineering does. In practice, most software engineers work more with information systems managers than with engineers.
Conclusion
Whether knowledge of the future is possible is a perennial question in philosophy. What is certain is that prophets are seldom right on any important question. So, I make no claim to know whether software engineering will ever merge with engineering. I claim only to know thatdespite the common term "engineering"software engineering is not now engineering.
References
1. Abran, A. et al. Guide to the Software Engineering Body of Knowledge2004 Version. IEEE Computer Society (2004), 1.
2. Davis, M. Defining engineering: How to do it and why it matters. Journal of Engineering Education 85, (Apr. 1996), 97101.
Footnotes
a. For a defense of this definition, see my article "Is Engineering a Profession Everywhere?" Philosophia 37 (June 2009), 211225.
b. Software Engineering Code of Ethics and Professional Practice (1999); http://www.acm.org/about/se-code. For history of this document, see my essay "Code Writing: How Software Engineering Became a Profession," Center for the Study of Ethics in the Professions, Chicago, 2007; http://hum.iit.edu:8080/aire/sea/1/book/index.html.
c. Michal Young and Stuart Faulk, "Sharing What We Know About Software Engineering," in Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (FoSER '10), ACM, 439442, argue that engineering has much to learn from software engineeringinadvertently making clear how much engineering's discipline differs from software engineering's.
d. For a darker route to this conclusion, see David L. Parnas, "Risks of undisciplined development," Commun. ACM 53, 10 (Oct. 2010), 2527. Note that Parnas, though a star of software engineering, is an electrical engineerboth by discipline and declarationlooking at software engineering the way knowledgeable engineers typically do.
Thanks to Keith Miller and Rachelle Hollander for helping me think through this column.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2011 ACM, Inc.
Comments
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
Displaying all 7 comments