Hacker News Reader

Comment by apalmer | Hacker News Reader

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.

View on HN

> 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.

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

Any place money is changing hands needs at least enough engineering, enough "application of scientific principles," to do it securely. Observably failing at that task means it ends up not being a pet food store. (It ceases to exist or becomes a scam instead.)

It really does. The pet food store app asks me for my cat’s allergies and medical conditions. Someone needs to be responsible if they fuck it up. Same with self driving cars - the whole idea of “engineering” is about quality and responsibility.

> the whole idea of “engineering” is about quality and responsibility

This is hilarious :-)

Making things that work has precisely zero relationship with quality or responsibilty or whatever shit you wish.

Of course you can pay me anytime for quality or responsibility or whatever :)

“Quality” is subjective, so you’re correct that it’s not about quality. A tool designed with a planned lifespan of 100 hour lifespan is just as much a product of engineering as one designed to last 10k.

Responsibility though is very much is a central component of capital E Engineering. The modern profession in many ways is a direct response to big newsworthy engineering disasters.

Responsibility does not have anything to do with engineering capital E or whatever.

If you pay me I can of course sell you some responsibility or whatever. This is called business.

When you hire a Professional Engineer there are minimum safety standards that they must meet. They can't charge you less and waive their liability. They are essentially required by law to "sell you some responsibility".

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

> 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)

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

I don't do a lot of frontend work. But when I did, the mocks were almost always best case; no mocks for when there was missing data (which was often). I did work on one project with an interaction designer, which was great --- having all the flows laid out was awesome, but it was only the happy path.

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.

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

Never heard of the rocket, but the software in at least the first two items is already developed to existing engineering standards by law.

oh it's Arian 5 integer overflow

The Azure and AWS outages affected hospitals.

You know there had to have been increased literal pain and suffering from patients while hospitals scrambled to fall back on old methods of coordination and communication.

This shit is serious and I'm tired of people arguing that our craft should not be taken seriously.

A lot of us work on infrastructure just as vital as bridges and tunnels, and with real world consequences when these things fail.

Take some responsibility.

The things you list illustrate @aplamers point that software "doesn't really kill people". If you asked the average person on the street, they might just barely remember the Boeing incidents and the rest they probably have never heard of. Even something as gruesome as the Therac-25 incident is probably unknown to most.

It's the rising tide of low-level everyday harm from software that is going to motivate the public to start coming after the software industry.

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).

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...

CE mark does not say anything about quality.

Same way critical software has all kind of sertificates.

The Cyber Resilience Act, conceived as a product security regulation on software, will mandate a CE mark on software products.

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.

> 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.

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.

> Rather, it is that systems are tested thoroughly enough, and designed with enough failsafes and redundancy

Yeah... That's one of the main reasons why engineers from most other disciplines have a lot of difficulty creating large reliable software.

Testing systems and adding failsafes are not nearly enough for system reliability, and not the best way to add it to software. It's almost enough for mechanical engineering... Almost, because it's not enough to make human interactions safe.

> Testing systems and adding failsafes are not nearly enough for system reliability, and not the best way to add it to software.

Then what is the best way?

Just like with systems reliability, nobody knows it well. But some things we do know are that keeping it simple quickly becomes more impactful than adding failsafes, and you need to design quality holistically from the top down, and not focus at failures or known failure modes.

And just to say, the fact that nobody has any idea how to engineer systems reliability is the main reason why we have a duopoly in large airplanes that everybody expects to turn into a monopoly soon. If we knew how to do it, companies would pop into the market all the time.

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

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.

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.

> 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.

> 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.

That doesn't really sound like an invalid analogy, you just don't need the same fire code for all structures but there are still fire codes that apply to building sheds.

I'm not sure what your point is. Like, ok, you came up with a structure that doesn't need a lot of structural engineering but clearly others do. So what are you trying to say?

That asking about a "software equivalent" isn't possible to answer without specifying an industry or what's being built. It will vary considerably between an human-implantable device or a game on your phone.

> 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.

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?

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.

    The sort of software flaw that would cause the application to not crash, but to mysteriously micalculate some load/shear/whatever limit seems unlikely.

Numeric instability is not only possible, but downright common in application software. You don't need exotic floating point issues to cause it.

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"

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.

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.

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”.

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

software is more like writing books than engineering

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

Things software engineers believe about history/government...

Therac-25 entered the chat

Reply on news.ycombinator.com