The mythical software engineer

Revisiting The Mythical Man Month recently, I am reminded of a bygone era in software development: an era in which documents were carefully formatted, ties were worn, and people who wrote software were engineers.

Today, there are more software "engineers" than ever, but how many of them actually understand–let alone apply–engineering principles? Some prominent members of the software development community, like Coding Horror's Jeff Atwood, have argued that software development shouldn't be viewed as engineering at all, but rather as "craftsmanship".

That sounds like a lot of "we couldn't get it to work, so we gave up".

First of all, what is an engineer? There is a precise definition to the word, yet it is not as strictly adhered to as, say, "doctor"¹. Anyone can call themselves an engineer, which renders the term meaningless. Some engineering titles, like facilities engineer, have been cheapened to the point of ridiculousness.

I tend to oppose government regulation, and support it mostly in cases where it is used as a tool to break up monopolies and eliminate gatekeepers², not to establish them.. However, there should be some means of enforcing what people can label their profession. Electricians shouldn't call themselves "electrical engineers", and, similarly, many software developers have no business using the word "engineer" in their job title.

On issues of title, the government usually leaves it to professional organizations to discipline their members. Doctors need to join medical organizations to practice, lawyers are called to the bar, and some fields of engineering, like civil engineering, have strict requirements regarding exams and licenses.

Perhaps the software development field is simply too young to have developed these institutions. Many people, including many software developers, are even arguing over whether software development is a profession.

Then again, it's not clear that professional licensure will do any good. For one thing, licenses are meaningful only if people are willing to respect them, and software companies have shown no interest in hiring only licensed engineers. In fact, most would vociferously oppose such a move, given that it would raise costs and reduce the labor pool.

Even so, I have long been confident that the software industry will proceed like the automobile industry, and continue to believe this will be the case.

In the early days of automobile production, each vehicle–or at least brand of vehicle–was bespoke, much like software today. Many argued that it was only possible to produce automobiles with small teams of highly skilled people–again, much like software today. Then Henry Ford came along and proved that a standardized, cheap, "good-enough" automobile created by large numbers of highly specialized–though low-skilled–workers was the way to go.

What will probably trigger the transition in the software field is a series of very high-profile software disasters. Many software projects have failed spectacularly, but few of those failures have had a large impact on society overall. As software reaches more corners of our lives, however, failures will be more frequent and more sharply felt, and pressure will increase on issues like using "standardized parts" (in software's case, libraries), which is just another way of saying that software development will need to be more of an engineering discipline.

It's unfortunate, but disaster is the means by which societies progress. The development of software "engineering" as a profession is no different.