Update 2021: While I still stand by many of the ideas expressed in this essay —
particularly “software is made out of feelings” — my views have been
significantly changed by two follow-ups. If you're interested in this topic,
you should read them both; they’ll teach you more than this will.
The
first, “Reverse Ungineering”,
by LVH, was a direct response to my post, based on personal experience being
trained as a civil engineer and working as a software engineer. Reverse
Ungineering changed my opinion almost immediately, so I actually held the view
expressed in the summary for a very short period of time after
publishing.
The second, “Are We Really
Engineers?”, by
Hillel Wayne, is a small but comprehensive ethnographic study of people who
have done both jobs. It’s extremely eye-opening, and made me realize just how
much of my idea of “engineering” was derived from a mixture of fiction and
popular culture, and not at all on any reality.
Both of these posts
bring to bear informative facts based on direct personal experience, as
opposed to my unsubstantiated hypothesizing. While I often still call myself a
software “developer” or “author”, and I think that comparisons to fields like
writing and research can also be illuminating, I do now call myself an
engineer as well. The experience of writing this post and reading its rebuttals
taught me an important lesson about not drawing conclusions from an imagined
experience that some unfamiliar category of person — in this case, civil
engineers — might have.
I am not an engineer.
I am a computer programmer. I am a software developer. I am a software
author. I am a coder.
I program computers. I develop software. I write software. I code.
I’d prefer that you not refer to me as an engineer, but this is not an essay
about how I’m going to heap scorn upon you if you do so. Sometimes, I myself
slip and use the word “engineering” to refer to this activity that I perform.
Sometimes I use the word “engineer” to refer to myself or my peers. It is,
sadly, fairly conventional to refer to us as “engineers”, and avoiding this
term in a context where it’s what everyone else uses is a constant challenge.
Nevertheless, I do not “engineer” software. Neither do you, because nobody has
ever known enough about the process of creating software to “engineer” it.
According to dictionary.com, “engineering” is:
“the art or science of making practical application of the knowledge of pure
sciences, as physics or chemistry, as in the construction of engines,
bridges, buildings, mines, ships, and chemical plants.”
When writing software, we typically do not apply “knowledge of pure sciences”.
Very little science is germane to the practical creation of software, and the
places where it is relevant (firmware for hard disks, for example, or analytics
for physical sensors) are highly rarified. The one thing that we might
sometimes use called “science”, i.e. computer science, is a subdiscipline of
mathematics, and not a science at all. Even computer science, though, is
hardly ever brought to bear - if you’re a working programmer, what was the last
project where you had to submit formal algorithmic analysis for any component
of your system?
Wikipedia has a
heaping helping of criticism of the terminology behind software engineering,
but rather than focusing on that, let's see where Wikipedia tells us software
engineering comes from in the first place:
The discipline of software engineering was created to address poor quality of
software, get projects exceeding time and budget under control, and ensure
that software is built systematically, rigorously, measurably, on time, on
budget, and within specification. Engineering already addresses all these
issues, hence the same principles used in engineering can be applied to
software.
Most software projects fail; as of 2009, 44% are late, over budget, or out of specification, and an additional 24% are cancelled entirely.
Only a third of projects succeed according to those criteria of being under
budget, within specification, and complete.
What would that look like if another engineering discipline had that sort of
hit rate? Consider civil engineering. Would you want to live in a city where
almost a quarter of all the buildings were simply abandoned half-constructed,
or fell down during construction? Where almost half of the buildings were
missing floors, had rents in the millions of dollars, or both?
My point is not that the software industry is awful. It certainly can be, at
times, but it’s not nearly as grim as the metaphor of civil engineering might
suggest. Consider this: despite the statistics above, is using a computer
today really like wandering through a crumbling city where a collapsing
building might kill you at any moment? No! The social and economic costs of
these “failures” is far lower than most process consultants would have you
believe. In fact, the cause of many such “failures” is a clumsy, ham-fisted
attempt to apply engineering-style budgetary and schedule constraints to a
process that looks nothing whatsoever like engineering. I have to use scare
quotes around “failure” because many of these projects classified as failed
have actually delivered significant value. For example, if the initial
specification for a project is overambitious due to lack of information about
the difficulty of the tasks involved, for example – an extremely common problem
at the beginning of a software project – that would still be a failure
according to the metric of “within specification”, but it’s a problem with the
specification and not the software.
Certain
missteps
notwithstanding, most of the progress in software development process
improvement in the last couple of decades has been in acknowledging that
it can’t really be planned very far in advance.
Software vendors now have to
constantly present works in progress to their customers,
because the longer they go without doing that there is an increasing risk that
the software will not meet the somewhat arbitrary goals for being “finished”,
and may never be presented to customers at all.
The idea that we should not call ourselves “engineers” is not a new one. It is
a minority view, but I’m in good company in that minority.
Edsger W. Dijkstra points out that software presents what he calls “radical novelty” -
it is too different from all the other types of things that have come before to
try to construct it by analogy to those things.
One of the ways in which writing software is different from engineering is the
matter of raw materials. Skyscrapers and bridges are made of steel and
concrete, but
software is made out of feelings.
Physical construction projects can be made predictable because the part where
creative people are creating the designs - the part of that process most
analagous to software - is a small fraction of the time required to create the
artifact itself.
Therefore, in order to create software you have to have an “engineering”
process that puts its focus primarily upon the psychological issue of making
your raw materials - the brains inside the human beings you have acquired for
the purpose of software manufacturing - happy, so that they may be
efficiently utilized. This is not a common feature of other engineering
disciplines.
The process of managing the author’s feelings is a lot more like what an editor
does when “constructing” a novel than what a foreperson does when constructing
a bridge. In my mind, that is what we should be studying, and modeling, when
trying to construct large and complex software systems.
Consequently, not only am I not an engineer, I do not aspire to be an
engineer, either. I do not think that it is worthwhile to aspire to the
standards of another entirely disparate profession.
This doesn’t mean we shouldn’t measure things, or have quality standards, or
try to agree on best practices. We should, by all means, have these things,
but we authors of software should construct them in ways that make sense for
the specific details of the software development process.
While we are on the subject of things that we are not, I’m also not a maker.
I don’t make things. We don’t talk about “building” novels, or
“constructing” music, nor should we talk about “building” and “assembling”
software. I like software specifically because of all the ways in which it is
not like “making” stuff. Making stuff is messy, and hard, and involves
making lots of mistakes.
I love how software is ethereal, and mistakes are cheap and reversible, and I
don’t have any desire to make it more physical and permanent. When I hear
other developers use this language to talk about software, it makes me think
that they envy something about physical stuff, and wish that they were doing
some kind of construction or factory-design project instead of making an
application.
The way we use language affects the way we think.
When we use terms like “engineer” and “builder” to describe ourselves as
creators, developers, maintainers, and writers of software, we are defining our
role by analogy and in reference to other, dissimilar fields.
Right now, I think I prefer the term “developer”, since the verb develop
captures both the incremental creation and ongoing maintenance of software,
which is so much a part of any long-term work in the field. The only
disadvantage of this term seems to be that people occasionally think I
do something with apartment buildings,
so I am careful to always put the word “software” first.
If you work on software, whichever particular phrasing you prefer, pick one
that really calls to mind what software means to you, and don’t get stuck in a
tedious metaphor about building bridges or cars or factories or whatever.
To paraphrase a wise man:
I am developer, and so can you.
