Software Engineering is a Misnomer

The juxtaposition of the term “software engineer” against other engineering disciplines strikes me as particularly awkward, in the same manner that “domestic engineer” seems like inaccurate terminology. There’s not much engineering going on in either case, in the sense that engineering is the job of building new products in a reliable manner within the context of strict definitions and regulations.

My sense is that software development is more of a craft than an engineering or science study — despite my bachelors and masters degrees in Computer Science, there was almost no actual scientific work done in those degrees (for what it’s worth, I did do some actual science, particularly in my masters: a replication study). Relatively speaking, the amount of actual engineering or science in the average developer job is negligible. You’re almost always utilizing existing tools, with existing solved solutions, putting them together in some new configuration. That’s not to say it’s an easy job, but it’s not engineering, and it’s definitely not science.

I generally think Uncle Bob Martin’s terminology on this is more accurate: software development is a craft. A lot of the work is mostly about perfecting the same concepts over and over, becoming intimately familiar with your tools and learning how to use new tools as they become available. Being able to deal with those outside of the discipline is very important. Skills generally taper off quickly, but experience is valuable from the perspective of having seen similar problems before, similar to an experienced carpenter who might not be physically more skilled than a young carpenter, but knows the tricks and pitfalls that are likely coming up in a given project.

With this in mind, I propose three things:

1. The vast majority of enterprise development and software developers change their messaging to more accurately reflect the fact that it is a craft as opposed to a science or engineering discipline. As such, less emphasis should be put on a college degree and more placed on prior experience regardless of where it comes from. An equivalent of trade schools, something not quite as expansive as a college degree but also not as skimpy as a coding bootcamp, fills out the educational backbone for this discipline.
2. Actual software engineers and computer scientists branch out to more rigorous concepts, leaving general enterprise development behind. For example, there is no ethics oversight on the vast majority of programming, despite impact. There are countless examples of computer software failing to work and people being hurt or dying, but the programmers are never held responsible because programming is not seen as an actual engineering job. In key areas, engineers should be vital pieces of the puzzle, similar to structural engineers and architects jobs in the context of a build site. Programmers are the builders, engineers are those who guide the development of the project and take responsibility for any shortcomings of the project.
3. A set of actual guidelines should be drawn up, similar to other engineering disciplines, to enforce what the job of these software engineers are. For example, thorough end-to-end and mutation testing is absolutely necessary for every component on an airplane (see the failures of the Boeing 737 MAX). Software engineers, similar to structural engineers, are responsible for making sure that adherence to guidelines is public and accomplished correctly. Oversight committees should exist to evaluate proposals and make sure that the rules aren’t being taken advantage of.

The fact that computer programming is relatively new seems to have escaped the impact of what people are programming. This is despite the fact that many programming jobs have arguably even more impact than many other disciplines with very high bars (law, pharma, structural engineering, etc). This doesn’t even start to touch the issue of ethics in programming, which also needs to be figured out sooner rather than later.