What is software engineering? Nobody seems to know. Everyone has an opinion, and everyone agrees that it is of the utmost importance, but there is little consensus as to what it is. But before addressing the above question, let us first answer the question: Why is it called “engineering”?
It is called “engineering” because early practitioners wanted to call it “software physics,” but that term was already in use. They wanted to call it software physics because they believed that the process of producing software could be formalized with such rigor that it would be on all fours with physics. Indeed, texts from the ’80s are populated with theories, derivations, tables, graphs, equations and formulae, apparently in an attempt to appear mathematical and scientific in nature. Within a few years however, the inadequacy of those books became clear, and the situation changed rapidly, and today’s texts contain virtually no formulae or equations. In spite of that, the title software engineering has been retained, authors claiming in their introductions that, e.g., “Software engineering employs engineering methods, processes, techniques and measurement.” Exactly what those engineering methods, processes, techniques and measurements are, is never stated, and the books never refer to them after the introduction. Of course SE is an artificial science, whereas physics and chemistry are natural sciences. Nonetheless, if it is a true science, and true engineering, we should expect to find some sort of system of laws and theories with experiments and predictions.
If we pick up an engineering book on how to design an automobile engine, we do not find sections on the waterfall model or the spiral model that we find in SE texts. We would expect to find sections on pistons and cams, and we would not expect it to contain sections on dashboard layout or cost estimates. And yet in SE texts we can find topics like screen layout and cost estimates, and we also see topics like team management, human factors, risk management and user interfaces, among others. Such topics are very important, but they belong to areas like marketing, management, IT and psychology, not engineering. Software production is very different from engineering, and it takes some imagination to see significant parallels between the two. A software engineer is no more an engineer than a novelist is a word engineer.
Perhaps the above observations are a bit harsh, and the problem is merely verbal and the title is a misnomer, a remnant from an earlier time. That is unfortunate, because the name implies scientific rigor, and opens software engineering to the charge that it is a pseudo-science flying under false colors. We would be better off if the name were changed to “software production techniques” or some such.
Back to the original question. There are many textbooks on software engineering on the market, and a survey of their indices and chapter topics reveals that they are very disjointed. One book will treat a topic as important, and the next book omits it entirely. About the only commonality to be found is the insistence that SE has something to do with engineering. That is due partly to the complex, amorphous nature of software production, and partly to a one-size-fits-all mentality. Software projects and programmers vary enormously, and some require vastly different approaches than others. Supposing that all software programs can fit under the same umbrella is a mistake akin to thinking that mechanical, electrical and chemical engineering can be lumped together.
To be sure, there are many areas of software research that are properly called scientific. Bearing this in mind, we should re-name software engineering, dividing it into (A) software theory/research, and (B) software production techniques.
[“source=ubiquity”]
