Unlike traditional engineering professions, there is a lot of soul-searching among software-oriented engineering students. Many people find the term "software engineering" meaningless. Many others believe software can never be "engineered". There is a well-versed skepticism among current influential professionals that software development is not worthy of being called professional engineering. Critics accuse universities of creating "software engineering" programs for the sake of pushing more people onto the unproven and unstable bandwagon of information technology.

What is engineering?
It ultimately comes down to what we mean by "engineering". The word "engineering" refers to the job that is done by an "engineer". Who is an engineer? Webster uses "engineer" to attribute builders of engines. Being obviously outdated, that gets us nowhere.

The most colloquial explanation of engineering is the application of science to social problems. That is why engineering is still being referred to as applied science at many places, the most notable being the [Faculty of Applied Science and Engineering at the University of Toronto]. The objection to software engineering is that there is very little science involved, but rather it is the codification of mathematical theories. Engineering involves the construction of something physical that would need to obey laws of nature, like a circuit, a bridge, or a new fibre. Software development yields nothing physical. A failed hard drive can make a sophisticated piece of software appear never to have existed. The power of software is not limited by physical laws, but rather by the ability of the developer to express what is conceived in a structural form. The most abstract mathematical equations, which may bear no physical interpretation, can be codified, and by doing so, software is in no way an application of science, but rather a new medium to express theoretical mathematics.

This view of engineering is rather old-fashioned, and to a certain degree also somewhat irrelevant. To advance this article, a distinction is hereby made between engineering and professional engineering. The distinction is by no means subtle. In fact, this is where the old argument loses.

You do not need to be a professional engineer, or an engineer in training for that matter, to engineer. Anyone can engineer. Anyone can make something. Engineering is when bored Grade 6 students make paper planes during English classes, an activity that is inexplicably discouraged by educators. Engineering is when a homeowner puts an extra brick to stabilize the fence. Engineering is when a burglar throws a Coke can to fool the motion detector. The act of engineering is the applied realization of scientific or common knowledge to solve social problems. It is to make a paper fold in a certain way so that air can lift it up and carry it to the teacher's desk. It is to apply the laws of gravity to battle against natural disturbances. It is to use past experience with existing technologies to devise a low-cost effective response as allowed by physical laws.

None of the three subjects under examination necessarily had an engineering education.

What is professional engineering?
It is now a fine time to define "professional engineering". As the term suggests, professional engineering requires a degree of professionalism. Professional engineers are licensed through a vigorous (i.e. bureaucratic) merit-based (i.e. taxed) system (i.e. inefficient structure) which requires years of higher education (or monetary substitutes) and relevant industry experience (i.e. mountains of paperwork). Then, is professional engineering an extension of engineering with more skills (and money) and paperwork?

The argument of critics goes back to the fact that engineering must involve a component of physicality. Since professional engineering is engineering, it is said that professional engineering must also involve a "real" product. That assumption is flawed. The building of circuits and construction of bridges as examples of engineering are irrelevant in this discussion because those physical constructions do not factor in the definition of professional engineering. It is obvious that an engineering degree is not needed to become an assembly line or construction worker. The only requirement there is to put a brick on top of other bricks or to fit a resistor onto a board is physical effort. If you are not lazy, you can help build a Pyramid or the Great Wall of China. With some added skills, you can control the cranes or screw doors onto the SUV.

It should be self-evident that none of the above described tasks fit the profile of professional engineering, even if the term "professional engineering" is yet to be defined in this article. This shows that professional engineering does not necessarily involve the physical construction of an object. Since such physicality is not a necessary condition, it becomes an optional component of professional engineering. Sure, the professional engineer may know how to build a brick wall, but that does not characterize professional engineering. Therefore, the focus of professional engineering must be distinct from engineering, and it must lie elsewhere. That "elsewhere" is design.

To architect or not to...
Professional engineering is a separate process from general engineering. It is the step before physical construction of solutions. Professional engineering is when ideas are formulated, models are sketched, prototypes are created, and the designs are tested. It is not to build solutions to problems, but rather refers to the process where solutions are sought to solve a particular problem. Labourers built the Pyramids and the Great Wall of China, but they would not have been able to construct such magnificent structures without the extraordinary achievements of the professional engineers who designed those structures. Professional engineering does not involve the actual realization of the solution. The task is to create a solution that can be realised. Here arises the engineering part of the job. The solution must be first and foremost realisable. It must be usable. A solution that cannot be realised is not an engineering solution, for it cannot be engineered. It doesn't matter who can realise the solution. Maybe high school kids can do it, or maybe a team of NASA technicians are needed. That is not a concern. The point is that the solution must be realizable. If it cannot be realised, it becomes a theoretical solution, and will no longer qualify as engineering.

And this is where professionalism comes in. The engineering specification requires that the solution is technically sound. Professional requirements necessitate that the solution is also socially sound. The product has to be safe. It must pose less danger than the problem it solves, and any such risk must be fully disclosed. It must be cost-effective, resource-efficient, and reliable. It must be environmentally responsible, considerate of human resource, etc. In other words, professionalism is social responsibility. That is why professional engineers have a code of ethics to which they adhere, and that is why they are willing to be held legally accountable for their mistakes.

Software engineering
Software engineering - rather, professional software engineering - now becomes a tangible term. It is the responsible design of realizable software solutions to solve real problems. While browsing the newly opened MIT OpenCourseWare, I came across their "6.170 Laboratory in Software Engineering" undergraduate course, where the introductory paragraph reads: "You will learn how to design software, ..., how to be an architect, not just a low-level coder." That neatly sums up the goal of software engineering, and professional engineering in general: it is to design, and design well, and not to labour over implementation details. A professional software engineer may know how to code in Java or Smalltalk, but that is not the focus of her job. It is to design a solution whose implementation is arbitrary and irrelevant. The important part is that the solution can be realised and serves the prescribed purpose. That introductory phrase could easily have been reworded for civil engineering students, for example: "You will learn how to design bridges, ..., how to be an architect, not just a brick layer." Learning the syntax of C++ is not difficult. Designing a language-insensitive program that serves a useful purpose correctly is.

Software engineers are not computer scientists with mandatory [management] credits, either. They are fundamentally different from each other just as electrical engineers are different from physicists. The interests of scientists into subjects are primarily theoretical, secondarily practical. The interests of engineers, on the other hand, are solely practical. If a solution cannot solve a real-life problem, regardless of how neat it is, it is useless. Engineers may apply theoretical research results to solve a real-life problem, but the key here, again, is the application of theory, not the development of theory. That is why computer science and software engineering have quite distinct focuses, and are therefore very different from each other. If such difference is imperceptible to most people, it is an indication of failure on the part of the educators to train and promote software engineers adequately, rather than a sign of failure of the software engineering profession as a whole.