A common trope, especially amongst software engineers, is that software engineering is not real engineering.

Lets take bridge building. I think we can all agree that the people that design bridges are real engineers. Lets work with the fictitious and renowned bridge builder, Mr. Van DerBridgen, to figure out what exactly defines an engineer. We call Mr. Van DerBridgen and comission a bridge to cross a small stream in our garden and once completed we drop a bomb on it and the bridge crumbles. We turn to Mr. Van DerBridgen flabbergasted. What happened to our bridge? How can the renowned Mr. Van DerBridgen be so incompetent, his bridge didn't last a single day. Mr. Van DerBridgen would rightly point out that the bridge wasn't built with that very peculiar use case in mind and he would be completely right. Mr. Van DerBridgen could build a bridge that withstands a bombing, but these situations have to be brought up and discussed.

Engineering is a balancing act. An engineers job is to build a product that meets a spec, or in other words a product that fulfills certain expectations. These expectations can be summarized as: purpose, cost, and time. What will the product be used for? What is the budge? What is the deadline? A bridge for people to cross the stream in your garden that must be built in less than an hour and cost less than $10 would be a plank of wood. Whereas if we give Mr. Van DerBridgen a million dollars and a year to build a small footbridge he could produce a work of art.

In software we also have great engineers. NASA built two voyagers, the curiosity rover, and got to the moon and all of these endeavours required software. Software that ran as well as any other part of the system. Why are these people not engineers?

Many of these people are engineers as well. The problem with most consumer facing software is the spec. The product must be ready yesterday and run everywhere. It has to work on every Android device, the 30,000+ of them, on all laptops running any operating system, and on all web browsers. The combination of environments is easily a million. So it has to work on a million devices and it has to keep working as more environments are created and people are going to try and break it and you have 2 weeks to do it. Oh, and we will change requirements half way through. As engineers, software engineers bring up these issues, but they have very limited power. The product "needs" to be built. They can try to remove some features or increase the deadline, but you can't say "hey, we will make this product and it will only run on Firefox 120 running on Debian 12". If that was an option we could have software that works very well, even better than how software runs now, which is already pretty well all things considered. It is impossible to make software with the expectation most companies have that is bug free. I once had a great team lead that said: "If we had 100% crash free rate we would be doing something wrong".

I would argue that consumer facing software engineering is one of the toughest if not the toughest engineering discipline. The environment in which software runs is changed constantly. Imagine if a bridge builder built a bridge on top of rock, but a year later the foundation was mud, and four months later it was water. How could we expect this engineer to take these things into account? Even the curiosity rover which is incredible works in a more confined environment than consumer facing software. Mars has a harsh environment, but it is an environment that can be accounted for. There are crazy sandstorms, it's cold, and radiation is higher than on earth. All these things make creating a rover for mars very complicated, but we know these conditions. If all of a sudden mars turned into a gas giant for a couple years because God decided to flip a bit Curiosity rover would fail.

The expectations on consumer facing software are ridiculous. The expectations of neither the user's nor the employer's can be met because the expectation is that it works for everyone. Given that constraint, most engineering value is lost because there is no realistic spec to work with. Despite this, software engineers do a great job and are the greatest of all engineering jugglers. They manage to build products that mostly work, in most environments, fairly quickly and cheaply.