Is Software the Ufology of Engineering Disciplines?

Not really. The difficulty to manufacture something isn't tied to the ability to engineer it. In fact, good engineers try to make the item easier/cheaper to manufacture. Take the AK-47 vs the M-16 - one used more exotic (for the time) materials with a more expensive and involved production process. The other was made with looser tolerances out of cheap stamped steel and wood that could be cranked out quickly. Yet they were both (eventually) of similar effectiveness.

These days, we have CAD and 3D printing available to craftsmen. If you want to build it out of metal and make it reproducible, you can build and print the parts to create molds to cast them from. Same thing for people how have a lathe and/or milling machine. In some cases you can get them used for a few hundred dollars. Record your dimensions and process and you can crank out copies of items with great results - no engineering training needed.

Other way around. The difference between engineering and building is that building refers to the building of a component in isolation, while engineering is about the building an entire system through the combination of multiple components. Most software — and all software that is actually used — is a built system.

> but one places a lot more rigor on the science

That'd be "professional engineering"; sometimes referred to as PE for short. We're talking about engineering (sans professional) here.

You have your "not an engineer" people who have built airplanes, cars, motorcycles and whatnot. They are good with their tools and they are able to make amazing things. Some of them might even be doing these things for a living.

Then you get your "real" engineers who need to measure and test and spec out and define limits and must be able to provably demonstrate that the bridge will not fall over.

In software you have your journeymen who build software for a living, they are good at what they do and they are building amazing things, and then you have your "engineers" who are building avionics for rockets and planes, the control software for nuclear reactors and so on. They need to prove their software works as intended and cannot venture beyond it's parameters etc.

Two very different professions, two very different types of people, yet both are (on the surface) doing something that appears very similar.

If you want to do anything outside of what's permitted by the book, that's generally when you call an engineer.

It does seem to me that a lot of calls for formalizing things in software is trying to skip over the engineering step and jump straight to a codebook that crystalizes the common engineered solutions into a list of dos and don'ts.

And to explore running studies a bit further. The second time you build a system goes so much better because you already know all of the weird edge cases. And the third better still because your failures in the second time has cured you of some of your hubris.

Even if you somehow bankrolled 50 repeat projects and did the statistics etc correctly, you're still going to get some weird artifacts because some of those teams have people who did the thing before. You'll learn the wrong lesson when the real lesson is "make sure Bob is working on Bluetooth because he's done it 10 times before."

Starting with people with no experience is likewise not interesting because nobody really cares what lessons you learn by turning a bunch of muggles loose on something difficult.

What you need to bankroll is 50 teams worth of people who spend their entire careers testing out a hypothesis. (And even then you probably need to somehow control their professional communities in some way because again who cares what some small group of people approaches a problem when you could instead have people who go out and learn things from other people.)

Writing isn't an engineering discipline. And all industries rely heavily on writing. Could it be that writing software is just writing for computers and as such could only by codified within another engineering discipline and not by its own?

Then, you can make a product that was applied engineering, but you can't replace all the others that not.

Civil engineering and friends have the advantage that is built on top of the universe, that despite claims to the contrary, was not hacked with perl!

But the software industry is not starting from centuries ago. We have the benefit of modern education and literacy rates, instantaneous global communication, centuries of experience and data in other life and safety critical fields to draw on to understand how to establish a reasonable level of safety in the face of uncertainty, vast libraries of knowledge and data that can be called upon online, and nearly a century of increasing regulation and professionalization in those fields. Sorry but that doesn't hold up to scrutiny.

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

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

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)

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.

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

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"

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

Our current age will show up in future ice cores as a massive spike; we affect CO2, Methane, Sulfates, and probably a lot more. Additionally we produce and have produced various synthetic compounds that will remain detectable in the environment for hundreds of thousands of years, if not millions.

In order to circumvent this lack of evidence such a society would have had to had a very small footprint, taken very specific industrial steps, and had a focus on research that wasn't exploited. This is highly unlikely - most of our lessons have actually been learned from exploitation, and most of our research facilities require astounding amounts of labour to construct. This isn't even touching on the social improbability of maintaining such a society.

Programmers hate it and rejected it.

To be fair, it does tend to create its own pathology. Instead of a layer cake made of congealed spaghetti, you tend to get over-engineering.

https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...

Software engineering leads to software over-engineering because unlike in physical material engineering there is no capital or material cost to push back against complexity. You can just add things, and add things, and add things, forever, and it costs very little (a bit of RAM and CPU but that's cheap).

I have this weird hypothesis that part of why methodical "correct" software engineering fails is that it succeeds. It is able to manage complexity, which allows complexity to grow without bound. A mountain of ugly shit will start crashing in mysterious ways if it gets too complex, which has the virtue of limiting complexity.

A root problem is that programmers tend to add complexity, not remove it, and the incentive structure of the software business tends to encourage this. Each new bit of complexity or layer is something you could build a business around, or a feature you could sell. Nobody pays for simplicity. It has value, often massive value, but it's not intuitive. In what other domain would you pay more for the absence of something? This would make sense in software since simplicity is harder than complexity, but it feels weird and wrong.

He said that programming today is “More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?'”. The “analysis-by-synthesis” view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant.

When I looked at SICP I saw one thing: an introduction to “thinking about programming” for people who will have to re-learn everything and will maybe use a few things here and there. The fundamentals matter but the application is the “everyone has a plan until they get punched in the face” phase of actual learning. There are much better ways to go about studying and learning and I found SICP lacking, among other course work that I think is taught backwards and makes it hard to reason and apply.

Read “Great Programmers” by Bram Cohen. The wisdom is there, but it’s lost on people.

Just my 2c.

Anecdotal, I had a coworker working on a new feature in a huge code base. I was trying to ignore the pseudocode planning they put on the board. After a moment of frustration I wrote down 6 conditionals that simplified what would become hundreds of new lines, to those 6 statement, and capture a few more corner cases they had not worked out yet.

Months later I got a green light on a total overhaul of the larger code base and we turned a massive code base into a fully automated and effectively bullet proof distributed system because I took the time to apply engineering principles to.the problem. The code wasn't always the most proper (I did things downright sinful) but the system was organized like an engineering project with interdependent subsystem instead of a rube Goldberg kludge of new.function on old. That overhaul too less time than any of the prior incremental feature updates prior.

Everything is aliens and a government cover up to those folks....even when you prove it's a floating trash bag they think you're a fool. There are a few rational commenters, but a lot of people that want to believe so bad they fall for all these grifters selling pseudoscience books and seminars.

It plain isn't and to claim that it is shows that you have done EXACTLY 0 research into the topic. This kind of bad faith engagement shows an utter lack of curiosity.

UFOs are huge in South America within just seconds you can find hundreds of sightings and discussions about them:

https://en.wikipedia.org/wiki/Varginha_UFO_incident

https://en.wikipedia.org/wiki/UFO_sightings_in_Brazil

https://www.vice.com/en/article/i-went-alien-hunting-on-chil...

Ufos are also a thing above Europe with the Belgian Ufo wave and the Rendlesham Forest incident being well known and seminal cases in UFO Lore

https://en.wikipedia.org/wiki/Rendlesham_Forest_incident

https://en.wikipedia.org/wiki/Belgian_UFO_wave

Africa also had for example the ariel school incident in Zimbabwe, one of the most well known UFO cases ever

https://en.wikipedia.org/wiki/Ariel_School_UFO_incident

https://en.wikipedia.org/wiki/UFO_sightings_in_Africa

Same goes for russia where after the cold war ufo sightings were discussed in offically declassified documents:

https://www.cia.gov/readingroom/docs/DOC_0005517761.pdf

Must I go on or is that enough to accept that "UNKNOWN THING IN SKY DOES WEIRD THING I DON'T UNDERSTAND" is pretty much a global phenomenon that can and should be scientifically investigated just the same as we would investigate everything else we find anomalous?

The "alien mummies" and "Buga sphere" came from South America, for instance. You can find UFO and alien contact reports from all over. Brazil has the Varginha incident, the Ariel School incident in Zimbabwe, the Voronezh UFO incident in Russia, Japan Airlines Flight 1628, to name a few examples. The UFO phenomenon isn't at all limited to the US.

Although to be fair, all of that's probably the result of American pop cultural influence.

They're not. There are however two factors greatly biasing your perception of UFOs. First, it takes a fair amount of effort to track down information in foreign language sources, so in general there's going to be a lot less English-language information on Chinese, Russian, or Japanese reports of UFOs. Second, militaries are going to both generate more UFO reports (thanks to military research programs that go awry, e.g., the circumstances behind the Roswell incident) and be a lot more open to collecting and investigating them (because of their ability to indicate the previous point). The US military being the largest and most well-funded in the world is thus going to generate the largest UFO report halo around it.

To be fair, software engineers can face similar liabilities in highly-regulated fields. When you're dealing with software regulated as a medical device for example, senior engineers do sign off on releases. You also see more processes associated with engineering carried out, particularly with respect to testing and documentation.

But several of our most popular languages don't (e.g., Javascript, Python), with Javascript having particularly ugly behavior.

> standard data formats

We're moving from more formalized data formats (XML) to far lesser formalized data formats (JSON). For example, the former gives relatively powerful tools (through XSD) to define types and what constitutes valid values, while the latter doesn't even have a standard date format. Perhaps JSON schema will one day invalidate most of this concern, but it's still pretty young and not widely utilized AFAICT.