Is software “engineering” ?

(TL;DR – Yes, but it isn’t architecture.)

This question, and the subject of vocational nomenclature in general, has been grinding my gears for ages, and deserves a rant of its own.

Sometimes it is difficult to know what to call myself. Internally, I’m a programmer. I like writing programs, I can do it reasonably well, and I can envisage useful occupations where programming is the bulk of my work. I read (but don’t necessarily do all the exercises in) books such as The Art of Computer Programming.

The problem is that mere programmers are frowned upon by the business world, which generally looks more favourably on developers, systems analysts, and most of all, software engineers. Programmers do little more than type the code that their more expensive betters tell them to, after it has been filtered down through layers of actual design.

Okay, so you and I know that these various titles are barely distinguishable, and then only by the attitudes towards them taken by people who are largely disinterested in what they entail. Human resources research will provide different job descriptions, prerequisites, and conditions for each case, but these are purely phenomenological — or they should be. They describe someone who can create programs, from initial design to final build.

Part of creating software involves collecting requirements, creating documentation, and generally managing the development of the software. This is what “software engineering” sometimes means. But if managing lists of requirements is engineering, then wedding planners are “nuptial engineers”. Sometimes “software engineering” means creating software to an acceptable standard using the appropriate technologies. If so, then cafe barristas are “beverage engineers”.

These are all worthy professions, but are they engineering? Are they about engines?

Is engineering about engines? I think that it is, or more generally about physics and the behaviour of objects in the real world. An “engineer”, we imagine, is someone who knows the physical science relevant to their specialty, has a general grasp of the scientific method and statistics, and can construct machines (or molecules, in the case of a chemical engineer) in their specialty that will behave within parameters defined by known physics. Software doesn’t behave according to physics: a single bit error can potentially change a program to an extent far beyond the effect of an extra rivet on a device; and margins of error in the prescribed components of a program will seldom improve its reliably. 99.9% of the interesting properties of software are independent of the hardware it is running on.

I have known several “true” engineers, and consistently appreciated that they have an ability to reason about physical systems that programmers, computer scientists, or even software engineers cannot match. At the same time, the logical concepts required to understand any nontrivial program are alien to almost all of the physical sciences (some notable exceptions could be made, such as thermodynamics or computational genetics).

I lean towards descriptivism in language, and so I encourage my readers to be skeptical of anyone who claims to define, from authority, what words mean (including me). Language is defined largely by usage, and communication should generally be formulated to ensure the recipient understands its meaning.  Engineering, to me, means working with machinery.  Over time it can change to mean other things, but preferably change comes through extending the word to cover inherently similar notions.

It occurred to me, while playing Manufactoria, that creating computer programs is engineering. Because a computer is a universal machine: it’s a machine that can mimic any other (computational) machine, and the bit of extra machinery that completes it is its software.

So software engineers exist. There still remains the stigma on the title “programmer”, but that’s another problem. Am I a software engineer? No, I’m still a programmer, but I suppose I could justify (to myself, at least) the title of software engineer if the need arose. (And after all, all that computer science I studied at university has now migrated into the engineering department…)

What about “developer”?  I wasn’t fond of this one even before Steve Ballmer made his famous speech.  It’s one syllable more expensive and far less precise than “programmer”; almost any job in the 21st century involves developing something.  Again, this title exists because of the ridiculous stigma on “programmers”.

More egregious than “software engineer”, is the term “software architect”. It is more pretentious, and the connection between building buildings and creating software is purely by analogy. Introducing yourself as “an architect” when all you do is design software is about as honest as introducing yourself as “a chef” and neglecting to mention that you maintain on the books at an accountancy firm.  Worse, it reinforces the outmoded and unproductive conception of software as something that is designed by a designer before being built by a builder.

Descriptivism doesn’t mean not caring about words. Some words for things are arguably less descriptive than others, and consciously using them to imply something beyond what other terms would convey is suspect. Such is the case for certain job titles. Language in active use will naturally adapt to improve clarity or efficiency. Changes to language which do neither of these things, but are imposed primarily to impart a grandiose spin on job titles, should be resisted.  What is wrong with “lead programmer” or “senior software engineer” ?  Nothing, except they don’t portray their wearer as a fashionable artistic type.

We can honestly, but metaphorically, refer to the high-level design of a piece of software as its architecture.  But we should not use it as a job title, because it obscures the fact that there is no qualitative difference between high-level design and the design decisions made through the entire program by all its programmers.  And it carries too much dishonest baggage (as distinction in status compared to other programmers, and reinforcement of an artificial separation of responsibility) to be excused as a useful approximation.

It’s going to take something more profound than Manufactoria to convince me there are such people as “software architects” — people who call themselves that are going to have to accept that, internally, I see them as mere “lead programmers” and “chief software engineers”. ;-)