I guess that I’m an engineer. I have a degree in Electrical and Computer Engineering. I have a good grounding in mathematics and the sciences.
And I go to Software Engineering conferences.
This casual use of the term “engineering” by software folks has always bothered me a bit. It was Peter Naur’s suggestion in 1968 to attach the term “engineering” to software, which Helmut Goss (who was there) reports was meant to be taken tongue-in-cheek. Engineering builds on solid foundations in the sciences such as physics and chemistry. There is actually an element of science in software complexity and automata theory. But software engineering rarely ascends (descends?) to this level.
The IEEE states that software engineering is: “The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software” (IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.) Numbers, technology, nerd stuff—no people or life. But the IEEE identifies engineers as “promoting the development and application of electrotechnology and allied sciences for the benefit of humanity, the advancement of the profession, and the well-being of our members.” I like that “benefit of humanity” and “well-being.”
On one hand, the use of the term “engineering” is a caricature that stilts the expectations of its own constituency. “Architect” conjures another metaphor for what some of us do. It was proposed by Fred Brooks who himself expressed skepticism about the label until encouraged by Jerry Weinberg, who felt it was a good model for what we do. And Peter Naur (again) would say in 1968 that software should look to the architect Christopher Alexander for inspiration. Both “software engineer” and “architect” reflect internal value; engineering is about delivered value.
Software engineering lifts its moniker from a sense of formal envy that characterized its search for identity in the 1960s. But little of the engineering profession is either quantitative or systematic. In fact, the bulk of engineering is about management, contract administration, and project management. 60% of surveyed Canadian engineers over 45 report their job responsibilities are primarily managerial (Engineering and Technology Labour Market Study, Engineers Canada, 1990). Software engineering literature has a significant qualitative side: Count qualitative results as you thumb through ICSE proceedings.
Software academics too readily don the engineering mantle, and there are dangers that the metaphor masks the bulk of its foundations of design and method that are dynamic cycles of fashion rather than invariants of nature. On the other hand, as it seeks its identity, software should learn from any discipline it can.
Further, as we look at engineering and software, we find that there is nothing that delineates them as formally separable concerns. They characterize arbitrary definitions from society rather than laws of nature. Much the same is true about the supposed division between architecture and digital system design. So it is with any broad element of upward human endeavor. Half of all engineers work in more than one engineering discipline over their careers, and more than 65% work in more than one industry. These labels have more to do with our desire to belong (the discipline focus of the software engineering definition) than to reach out to other disciplines and society (as the broader engineering definition implies).
Software engineering is not, and should not become, engineering. It continues to seek an identity of its own. In the mean time, it’s probably better that it live alongside engineering—it might as well have neighbors who are a good influence. But art, psychology, and a host of others should also be in the neighborhood.
