Software engineers are not engineers?

Recently I stumbled across this post:

https://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/

He claims that software engineers shouldn't claim themselves as "engineers" at all, and that it undermines a long and stablished tradition and school. Apparently, we "software guys", don't like to call ourselves programmers, and we like the term of software engineers, or software developer.

In a first read, you might agree. I mean, how can you compare a guy who builds website with a guy who builds bridges, or airplanes? We all know how software is prone to fail. From the renowned (and forgotten) blue screen of death, to the milliards of freezes, bugs and problems in our daily operations and work with computers and the like.

I am an electronic engineer by education, but software developer by trade. In order to call "developers" software engineers, we have to go through exactly the same subjects in college (in our majors) as most electronic, mechanical or industrial engineers. I've seen computer science guys studying for fluid mechanics. Complaining about it, I give you that, but having to pass tough tests on that, several calculus subject, physics, and so on. That in combination with statistics, accounting and project management.

I'm not praising how the (Spanish) University system works. Far from that, as I actually think it could be extensively improved. I'm stating a point on whether the guys who write code "could" be engineers (note the "could").

First of all, an engineer is a person who designs, builds, or maintains engines, machines, or structures. (from the dictionary). A more pragmatic approach that I like better is "someone who uses and combines several fields of science and maths, to solve real world problems". But even if you take the former definition, we would be talking about engines, machines or structures. Source code is nothing but a bunch of structures trying to live together and communicate with each other.

Now, there are a few big differences between building a bridge and developing a software system. And those differences are what make software be more prone to failures (some types of software) than bridges.

First of all, when "defining" a bridge, everything is much more tied up. All specifications are clear from the beginning, and they don't change. You don't go to the architect and the engineer in the middle of the construction and tell him "hey, I know we were building a two lane road bridge, but could we add also a rail track and a pedestrian design walk? I'm sure that won't change much right?". This actually happens a lot in software, and guess what? It is OK for it to happen. Because engineers solve problems remember? Also, time to market is kind of key here. Software allows for nice techniques like continuous delivery, client side iterations, agile methodologies and all that jargon.  I can't really imagine building a power plant and giving tours to the final client every month or so, and allowing him to put the uranium bars here or there. Yet it is quite normal to build a web application "just for a few hundred thousand visits", and then see your servers overwhelmed by a TV ad, or a link on reddit. If a plane can hold 400 people, nobody will put 500. In fact the risk margins are way, way, way higher than in any software piece available. If a server accepts 1M requests per second, we will try to send 5M, just to see what happens.

Said that. Remember that there are many, many types of software projects.  From an online shop for a brand to the micro controller that manages the flow of sewage systems. From a mobile game app, to the software air controllers use. Or even the software mechanical engineers use to design their pieces, or architects to design their structures.

Each process, each system, each business problem or real life challenge requires a different set of resources and a different approach. We can do a lot of QA, either manual or automated testing, we can stick to the original specifications and put enough resources and time into a critical piece of software. And then it won't fail. OR we can be time to market sensitive, play with little resources and do "hotfixes in production" and keep solving business problems like real engineers.

So, are you a programmer or a software engineer?