This seems to have been written by somebody who has no idea what other engineering disciplines look like. Note how TFA has, like, 10 words about other engineering disciplines and instead goes on and on about some stretched analogy to UFOlogy.

Software engineering is absolutely an engineering discipline.

Now, full disclosure so you can adjust your dosage of salt: My whole professional career has been in software development. However, my 4-year degree was in a branch of Electrical Engineering discipline (Process Control) and I have a handful of small “cottage” control systems and embedded projects under my belt. I also regularly follow other fields of engineering out of interest (communications, DSP, robotics.)

But my biggest claim to non-software engineering fame is that as an intern, on my very first “real” project ever, I caused my very first outage, in which I brought down a factory. No, not an AbstractFactoryFactory; an actual factory producing actual copper tubes. It was supposed to run 24/7/365 and was down for at least a day and caused significant $$ losses and spawned a major incident report to the CEO.

With my “credentials” out of the way, here’s how I define engineering: Engineering is the intersection of applied sciences, economics and business.

The fundamental core of any engineering is applying the principles of your scientific discipline and empiricism to navigate an environment of imperfect, changing information by making reasonable, practical tradeoffs to build something useful within a given cost.

You'll note software engineering matches this definition perfectly. Any lack of rigor you may notice is simply a function of the cost and economics involved. And any discussion of engineering that leaves out economics and cost is fundamentally flawed.

As an example, medical software for radiation therapy machines have extremely stringent standards and controls because the potential cost is a literal human life. On the other hand your bog-standard CRUD To-Do app has negligible costs (and most likely correspondingly low revenue) and is just fine with negligible rigor.

But if you’re writing code to be deployed in a large microservice deployment, you do want some tests, because the potential cost is lots of lost engineering hours and happiness when cascading failures set off pagers at 3am.

Yes, we are winging it for the most part, because costs are so low. But so are other disciplines! The professor who taught us PID control systems was an industry veteran who walked us through a bunch of complicated math that I would not inflict on an LLM because that’s how you get SkyNet… and then said something like: “This theory is essential, but you should know that tuning PID controllers is a black art. There are just too many variables we cannot control, so experts basically tune the system in Production by trial and error.”

And they have similar problems! Buggy, poorly documented libraries? An early life lesson in embedded engineering is “Check the errata” because datasheets are essentially marketing materials. Shifting requirements? That’s how civil engineers end up constructing a right-angled bridge (https://news.ycombinator.com/item?id=44522579)

Again: The only reason software engineering seems less rigorous is because that’s how the economics work out.

Maybe someone who is experienced in other forms of engineering as well as software can keep me honest. But don’t let anybody tell you software engineering is not a real engineering discipline.