Is Software the UFOlogy of Engineering Disciplines?

What Counts as “Engineering”?

• Commenters disagree on definitions: some reserve “engineering” for mathematically rigorous, licensed, safety‑critical work; others use a broader sense of “system design under constraints.”
• Distinction is drawn between “engineering” and “professional engineering (PE)” with legal responsibility, exams, and liability; most software work clearly lacks this.
• Several note that even in civil/mechanical/EE, much day‑to‑day work is rules of thumb, trial‑and‑error tuning, and CAD-driven design, not constant deep math.

Software as Craft, Building, Plumbing, Writing

• Many say most software work is closer to craft, construction, or plumbing: assembling and configuring components others designed.
• Comparisons to custom motorcycles vs mass‑produced cars; journeymen vs “real” engineers who must prove safety margins.
• Others frame programming as a kind of writing or language work—structuring concepts and coordinating humans and machines—more than applied science.

Where Software Looks Most Like Engineering

• Safety‑ and security‑critical domains (avionics, nuclear, medical devices, crypto, real‑time systems, some networking protocols like QUIC) are cited as genuine software engineering: formal specs, extensive testing, documented limits, sign‑offs.
• Even there, high‑profile failures (Boeing 737 MAX, Starliner, Therac‑25) show that “by the book” processes and standards can be outdated or misapplied.

Rigor, Evidence, and Formal Methods

• A recurring complaint is the lack of solid empirical studies on practices like TDD or methodologies; large controlled experiments with professional teams are economically unrealistic.
• Formal methods are held up as a route to “true” engineering rigor, but are rare, hard to apply to fuzzy requirements, and mostly confined to narrow domains.

Regulation, Risk, and Harm

• Some argue software isn’t regulated because it “doesn’t really kill people”; others list incidents (medical devices, planes, outages, data breaches) as evidence of real harm.
• Expectation that after a sufficiently dramatic software disaster, governments will impose engineering‑style regulation (EU’s Cyber Resilience Act, CE‑like regimes for software).

Complexity, Tooling, and Maturity

• Tooling (types, tests, linters, VCS, orchestration) is seen as mature; the social/process side (how to design, document, measure quality) feels more like ufology: lots of belief, little hard evidence.
• Several note that software’s near‑zero marginal cost encourages unbounded complexity and over‑engineering; nobody pays directly for simplicity.
• A “three tribes” view appears: software as engineering, as making/product, and as math/philosophy—all valid, each demanding different notions of rigor.