Software engineering is...

The debate about whether software engineering is really "engineering" has gone on since the term first came into popular use after the 1968 NATO Conference on software engineering.

Since I teach software engineering at Boston University, I'm highly motivated to assert: "Of course software engineering is engineering." Joking aside, it is clear to me that software is "engineered", no matter how it is created.

Perhaps the place to start is to see how Webster's Dictionary defines "engineering" :

1. The practical application of science to commerce or industry.

2. The discipline dealing with the art or science of applying scientific knowledge to practical problems; "he had trouble deciding which branch of engineering to study".

This definition squares well with the commonly-heard expression, "to engineer a product".

More specifically, all engineering fields are characterized by the following features:

a. Formal communication methods -- mechanical engineering uses drawings and engineering change orders, electrical engineering uses schematics, civil engineering uses elevation and detail drawings, etc.

b. Process-oriented -- creating a product ad hoc can be accomplished only when a very small number of like-minded people are involved; otherwise contributing, reviewing and modifying the information comprising an engineering project must follow some defined procedures.

c. Conscious of time, requirements and economic constraints -- in most cases, someone or some organization is investing in a product to address a particular market opportunity, and usually does not have endless patience and cash.

d. Relies on science -- try convincing yourself a bridge will be sufficiently rigid by looking at a sketch on paper; science provides some definite answers through math and logic.

e. Relies on body of knowledge -- when science can't quite provide a definite answer, past experience can.

f. Must sometimes meet standards and code on account of legal liability -- a major consideration in consumer products.

e. Iterative -- much of engineering is creativity, and creativity rarely follows a straight path without errors and insights.

So is software engineered? Let's look at each of these characteristics.

Formal communication methods and process -- Even if programmers engage in ad hoc code-and-fix, one can say that "formal communication" and "process" occurs nonetheless. It just is not particularly apparent to the casual observer since these things largely happen in the programmers' heads. Certainly there is concrete process in almost any software development organization today: source code control, bug reports, requirements documents, agile activities.

Conscious of time, requirements and economic constraints -- A reality of any business, including software. Agile has done a lot to bring prominence to requirements through its user stories.

Relies on science -- Many programmers don't have formal computer science training. Those who do, however, carry with them a store of algorithm and abstract data structure knowledge that influences their judgment, whether they are aware of it or not. Sometimes they explicitly apply this knowledge.

Relies on a body of knowledge -- There's nothing like experience, and programming is no exception. The best code is written by programmers who have written similar things before.

Must sometimes meet standards and code -- Certainly is true of software used in any sort of aviation. Internally, companies define (and increasingly apply) coding standards.

Iterative -- Would anyone disagree? Agile has done a lot of make this characteristic plainly clear.

The bottom line is that all software development is a form of software engineering, done in a wide range of professional quality.

OK, so what? We can argue that software engineering is engineering, but what is the value of this realization? Does this realization lead us to change how software is developed so it is created faster, better, and with more pleasantness all around?

I'll address these questions in the next few posts.