[apalmer]

This again? In general, Software Engineering is not engineering.

It's not a technical issue, it's a 'software doesn't really kill people so government doesn't intervene in it'. In the case where the software is life and death it's generally developed in ways similar to 'real' engineering

Fundamentally folks built building/structures without engineering, just so consistently caused death and destruction that govt stepped in and started requiring licensed trained folks, approval trails etc. without this real world intervention regular physical 'engineering' the same crap shoot as software engineering.

[isodev]

> it's a 'software doesn't really kill people so government doesn't intervene in it'

I think we've reached the point where this is no longer true - self driving cars, supposed robots you can take home, LLMs being unleashed to randomly guess at medical data or write software to do verification or sensitive tasks.

I think software engineering is definitely engineering, we've just been successful in lobbying against proper regulation. But all that is changing, the EU is introducing the Cyber Resilience Act and I think we need a lot more of that.

[array_key_first]

Software companies are definitely flying too close to the sun here. I don't think this is sustainable, at all.

[binary132]

Pet Food Store App does not really need Real Engineering, no

[toast0]

> This again? In general, Software Engineering is not engineering.

Software Engineering is definitely Engineering. But Software Development usually doesn't practice it. I've got a degree in Computer Engineering and took SE courses and at least at the companies I've been at, we never did any of that. You can't use formal methods without a formalized specification, and I never even got a written specification of any project I worked on in 20+ years. Regardless, Software Engineers don't wear stripey hats and are not real engineers.

There's not much structual engineering in single family home construction either. A couple story wood frame building needs to be pretty exotic to have structural issues (but soft story buildings used to be common and collapse with strong earthquakes)

[tsss]

You never got a properly dimensioned wireframe model from your UI designer? That's a specification too.

[GrumpyYoungMan]

Software "engineering" doesn't kill people instantly in a flashy way, sure, but it has become more like leaded gasoline, a widespread low-level harm whose effects are increasingly evident in hindsight. You pretty much can't go more than a couple of days without hearing about another massive consumer data compromise by hackers, CVE, major services outage, etc. At some point, there is going to be a software related incident that is bad enough that the public and government is going to demand accountability.

[ge96]

Boeing, insulin pumps I could think of, missiles exploding on the pylon, lot of ways software can (almost) kill instantly, like that rocket that started flying sideways due to I think switching measurement units

[jandrewrogers]

Almost no physical engineering requires licensing either. Most things are YOLO-ed without a licensed engineer because it isn't required and adds little value.

The issue is that software systems are qualitatively more complex than any physical system due to their intrinsic malleability. Physical systems are sufficiently simple that formal verification methods are actually tractable (and used).

[isodev]

Physical products require the CE mark [0], so software systems (especially the complex ones) should be able to meet the same standard because they’re used in places where bugs and glitches can cause harm.

[0] https://europa.eu/youreurope/business/product-requirements/l...

[64718283661]

Many engineered physical devices can't cause harm to their end users the same way you say software cannot. And many software applications can cause harm to people both directly and indirectly. See social media, or hacks and data leaks which can destroy the lives of individuals or countries.

[NitpickLawyer]

> In the case where the software is life and death it's generally developed in ways similar to 'real' engineering

I think even that is highly romanticised by people. Take Boeing's two big blunders in recent years. The Max and Starliner both had terrible terrible software practices that were "by the book". The problem is "the book" really changed a lot, and the behemoths haven't kept up.

It used to be that "the NASA way" was the most reliable way to build software, and there are still articles and blog posts shared here about the magical programming "rules", but frankly they've been left behind by the industry. On the Starliner project Boeing was seen as the "stable, reliable, tried and true" partner, while Dragon was seen as the "risky" one. Yet Boeing doing everything by the book had 2 loss of crew problems in their first uncrewed demo flight, one relating to software timers, and their crewed demo flight was plagued by problems root-caused to a lack of integration testing. Again, everything by the book, and they failed multiple times on the happy path! The book has to be rewritten, taking into account what the software industry (tech) has "learned" in the past decades. Just think about man-hours and amounts of billions that went into tech software engineering and you can see that obviously NASA can't keep up.

[wavemode]

I think, rather, you're romanticizing what "real" engineering looks like.

Real engineering doesn't mean that mistakes are never made or that there are never bugs. Rather, it is that systems are tested thoroughly enough, and designed with enough failsafes and redundancy, that safety concerns are mitigated.

The problem in the Boeing case was not that the software had bugs. Lots of aviation software has bugs, it's actually very common. Rather, the problem was that they did not design the system to be safe in the event a bug occurred.

How that looks exactly tends to differ depending on the system. As a common example, many aircraft systems have other systems which monitor them and emit a warning if they detect something which doesn't make sense. Though this would've required Boeing to create technical material for pilots on how to respond to this new type of warning, which would've required training updates, which would've required recertification of their plane design, the cost of which Boeing desperately wanted to avoid. Fortunately (unfortunately), FAA oversight had become very lax, so Boeing instead just downplayed the safety concerns and nobody asked any questions.

[keeda]

Software engineering absolutely is engineering. Engineering is not defined by presence of regulations. Engineering is about solving practical problems within the constraints of physical reality and economics.

TFA (and your comment indirectly) seem to be about the lack of rigor in software engineering. However, any discussion of engineering that leaves out economics and costs is fundamentally incomplete.

The only reason most software development seems to have less rigor is because the economics of most software projects permit it. Other domains of software engineering where lives are on the line definitely have high levels of rigor.

I wrote a lot more in this other comment: https://news.ycombinator.com/item?id=45849304

[rdiddly]

Safety is not the only parameter that can be engineered (obviously), nor is it the only one subject to regulation. Efficiency for example is regulated, like when the EPA states what an appliance must accomplish while using some amount of energy. Meeting that guideline takes engineering.

[jayd16]

It's an interesting discussion.

Developing an application is applying techniques but by nature, you don't really build the same application many times such that you can come up with rules that the daily grunt applies without thought.

What is the software equivalent of spacing studs interspersed with fireblocks that we're not doing?

In software, easily repeated steps and proper practices are moved to the runtime/language/compiler etc.

Is it too conceited to argue that each application is more unique than each housing structure? I'm not sure. But we do actually have many many practices in place that are automatically handled.

[wavemode]

> Is it too conceited to argue that each application is more unique than each housing structure?

I would say the exact opposite, actually. Two random software applications designed for the same purpose are likely much more similar to each other than two random buildings that were built for the same purpose.

This is because, for practical reasons, the software applications are likely just going to be slight variations of the same base. Unless your application is extremely intricate, most of the complexity (and most of the code that's executing) is actually in the kernel and the libraries. You're mostly just reusing those shared components and arranging them in a slightly different way.

[HeyLaughingBoy]

> What is the software equivalent of spacing studs interspersed with fireblocks that we're not doing?

You're comparing apples to hockey pucks. For the analogy to hold, you need to specify what industry the software is for. i.e., if I'm building a garden shed, I don't need a specific stud spacing or even fireblocks at all. Hell, I can build it from raw timber if I have enough of it.

[RHSeeger]

> What is the software equivalent of spacing studs interspersed with fireblocks that we're not doing? > > In software, easily repeated steps and proper practices are moved to the runtime/language/compiler etc.

At least in my opinion, that doesn't make them _not_ the equivalent of spacing studs interspersed with fireblocks, etc. It just makes it automatic... the same way that contractors buy materials that have certain things build into them (weather resistant, fire retardant, etc).

Just like it's entirely possible to build software without using common libraries (roll your own, etc); one can do the same with buildings. The only difference is the official rules requiring they way things are done.

[estimator7292]

Who makes the software that "real" engineers use to design bridges? Can developers of such software afford to be any less rigorous than the "real" engineers?

[NoMoreNicksLeft]

Most software flaws would manifest during the design phase, and a crashed application just causes design delays (pushing back bridge opening, but still). The sort of software flaw that would cause the application to not crash, but to mysteriously micalculate some load/shear/whatever limit seems unlikely. You'd almost need a silicon bug, a floating point unit that just totally shits the bed and comes up with a retard result.

That said, I'm in general agreement that the software developers should be as rigorous as the "real" engineers, but that's often just impossible from an office politics standpoint.

[mitthrowaway2]

When a software error can simultaneously shut down hospitals, air transport, ground transport, emergency services, and telecommunications, I don't see how the design of that software system should be held to a different legal standard than the design of, say, a steam turbine at a power plant, or the electrical grid itself.

https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...

> "The outage disrupted daily life, businesses, and governments around the world. Many industries were affected—airlines, airports, banks, hotels, hospitals, manufacturing, stock markets, broadcasting, gas stations, retail stores, and governmental services, such as emergency services and websites. The worldwide financial damage has been estimated to be at least US$10 billion"

[sarchertech]

It’s because it doesn’t directly kill a bunch of people all at once in a way that causes public outcry.

If it weren’t for the many large scale “flashy” engineering disasters that caught the attention of the average person, we wouldn’t have any of the Engineering regulations we have today.

My guess is that at some point some piece of software will kill enough people or cause a large enough economic disaster that we’ll start seriously regulating it.

[bsoles]

This again? You don't need a license to be an engineer. Every graduate of an engineering school at an accredited university/college IS an engineer. People seem to conflate an "engineer" with a "professional engineer". The two are not the same; the latter requires a license. At least in the US.

[sarchertech]

There are states that regulate the bare term “engineer” depending on the context.

And all states require a license to offer certain engineering services, so practically speaking in certain fields you can’t “be an engineer” without a license.

For example in most (all?) states you can’t hang up a shingle adverting yourself as an “Engineer” doing structural work without a license even if you aren’t calling yourself a “Professional Engineer”.

[dec0dedab0de]

I always liked the RMS take that programming is a craft.

[NaomiLehman]

software is more like writing books than engineering

[empath75]

Government did not invent the discipline of engineering. This is just completely backwards. How do you think all of those engineering organizations came up with those manuals and regulations, were they not doing any engineering until they published a manual? Complete nonsense.

https://www.youtube.com/watch?v=_ivqWN4L3zU

[ch4s3]

Things software engineers believe about history/government...

[thenthenthen]

Therac-25 entered the chat