Is Software the UFOlogy of Engineering Disciplines?
86 comments
·November 7, 2025giantg2
gchamonlive
It's solving and building, but most of all it's language. It's all language. Either telling the machine what to do or coordinating a group of people cohesively.
HPsquared
That's where engineering fits in. It's in the knowledge and information space, you make things like plans, arguments, decisions, documents.
That's not to say it all needs to be written down; someone can do the "engineering" of a small project all in their own head and then implement it themselves.
The engineering process itself is a form of knowledge work. A single person can do both tasks of course.
cachius
You mean communication, the transfer of ideas. Already hard between humans, machine language and operation is completely foreign.
ratelimitsteve
I actually read an interesting study, probably here, about software engineers. It turns out that for as much emphasis as we put on mathematics we actually tend to be better at language, and that even our penchant for maths is less in the way of calculation and more in the way of definition and expression (which is to say, making it the language numbers speak and learning it that way).
sam_lowry_
It would be nice to have a reference.
reedlaw
Agreed, in the sense that software development is an iterative process of trial and error similar to custom car building. But software isn't like a car. It's more like a car factory. It should produce something of value repeatedly.
9rx
> Most of software isn't engineering, it's just building.
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.
7thaccount
Thanks for bringing up the PE distinction. This kind of argument comes up here ad nauseum. People have different views and we argue semantics.
There is engineering as a discipline (e.g., mechanical, electrical, industrial, civil, aerospace...etc.) and engineering in a more colloquial sense like "I did some hillbilly engineering and rigged up a pea sheller". Both involve solving problems.
The former typically involves the person going through a rigorous 4-5 year program where they take a bunch of advanced math and physics classes and a ton of other classes (including coding and robotics as well as more specific classes such as power electronics) that teach logical thinking and problem solving. I'm always amazed that I can more or less talk to any engineer across the country (different state, different university, different engineering discipline) and still recognize their training and that hyper analytical mindset and feel the kinship. That of course doesn't mean that there aren't similar analytical people that went in other directions, but the training is a real thing.
A professional engineer passed their fundamentals of engineering exam, got their degree, and then took their professional engineering exam. You used to have to get 4 years of work experience before applying, but I think they got rid of that. It's an awful 8-hour exam with a pretty low pass rate. Honestly though, the PE usually just means the engineer was willing to spend 3-6 months prepping for the exam and has a need for the license to stamp papers. A lot of engineers never get it if they don't need it. I believe you need it in some cases for court cases.
As far as software engineering goes. It seems to be a discipline that matches the second colloquial definition more in a lot of cases. In some cases they have actual software engineering degrees where the student takes all the standard intro engineering courses (calculus, linear algebra, statistics, differential equations, statics, dynamics, circuits, thermodynamics) before doing the core classes distinct to that major. In that case, I'd call them an engineer due to the training and think it's an appropriate job title even if they get a job slinging corporate java, which would not typically be viewed as traditional engineering. So they're an engineer...not necessarily doing engineering. Does that really make sense? My own definition breaks down if we apply this to the same engineer becoming a garbage man. They're still an engineer by training, but they're most definitely not doing engineering anymore.
Clear as mud? As an engineer I now must flog myself for my own internal inconsistencies.
HPsquared
A house comprises many parts. A custom motorcycle has many parts. These things are designed and built to established practices, but in 99% of cases they aren't really "engineered" with calculations and formalised decision-making processes and the like.
9rx
> A house comprises many parts. A custom motorcycle has many parts.
Hence why they are engineered. I suspect you mentioned houses because the people who build houses are often referred to as builders, but that is because the people working houses often only do work on a single component. The system as a whole is referred to as engineering, though.
> with calculations and formalised decision-making processes and the like.
You too seem to be confusing "engineering" with "professional engineering". While societies of professional engineers would like people to think that engineering is defined by mathematical and scientific rigour, that's not how anyone actually uses the term in practice. The "software engineering" label wouldn't exist if they did.
amelius
Most of software is just plumbing.
HPsquared
And plumbing is a highly skilled and essential profession. And a lot of plumbing work involves engineering to a greater or lesser extent.
Marshferm
If I understand your analogy correctly, what science in involved directly in software dev other than used directly in already existing models like medicine? (and even this isn't exactly science, as medicine is practice, not analytic discourse). Engineering relies on science, particularly building, vehicles, etc.
bogdanoff_2
I'm thinking things like: do you know what's the latency and throughput of your system, and how it is affected by different conditions? Based on this, people who work on real-time systems (including video games) would be the closest thing to the engineers of the software world.
Marshferm
Right, but then it's A/B cog-sci, which I think is no longer science, but practice completely under software, and in a sense, practice that's no longer science, but behavioral modification.
gosub100
Then you get paradoxes like why the rigor doesn't work in practice. These expensive CS books mathematically prove a map has faster access than a vector because it uses a binary tree. Yet the vector works faster because the CPU pipelines sequential operations very efficiently.
layer8
CS proves that a binary tree is faster asymptotically, and that’s still true and very much of practical relevance regardless of the CPU you use.
auggierose
No, they don't. A vector has faster access than a binary tree, O(1) vs. O(log n). Maybe read some of those expensive books.
If you talk about editing the data structure, then it depends.
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.
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.
null
null
throwaway838112
[dead]
shagie
I'm going to refer to Philosophy of Computer Science ( https://news.ycombinator.com/item?id=20912718 https://news.ycombinator.com/item?id=10388603 ) and say "its not an easy or decided problem".
Section 3 has about 100 pages (in the pdf - I'd have to dig around to find the hard copy) that tries to look into what computer science is. Section 3.10 starts comparing it with engineering... and noting that it's looking at computer science rather than programing aspect of it. Part of the questions being asked is "is computer science a science?"
I'm going to highly recommend the book for those interested in these questions. I'll also point out that across its thousand(!) pages, this book is in large part a survey of the literature of tens of thousands of more pages on the subjects.
I don't believe that most people are approaching software development (be it called computer science or software engineering) with either the mindset of a scientist or an engineer (there are times when one of those mindsets is necessary) Rather, I agree with a later section in it...
3.14.7 Is CS Magic?
The great science-fiction author Arthur C. Clarke famously said that “Any sufficiently advanced technology is indistinguishable from magic” (http://en.wikipedia.org/wiki/Clarke’s_three_laws). Could it be that the advanced technology of CS is not only indistinguishable from magic, but really is magic? Not magic as in tricks, but magic as in Merlin or Harry Potter? As one CS student put it,
Computer science is very empowering. It’s kind of like knowing magic: you learn the right stuff and how to say it, and out comes an answer that solves a real problem. That’s so cool. —Euakarn (Som) Liengtiraphan, quoted in Hauser 2017, p. 16
Brooks makes an even stronger claim than Clarke:
The programmer, like the poet, works only slightly removed from pure thought-stuff. He [sic] builds castles in the air, creating by the exertion of the imagination . . . . Yet the program construct, unlike the poet’s words [or the magician’s spells?], is real in the sense that it moves and works, producing visible outputs separate from the construct itself. . . . *The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.* (Brooks, 1975, pp. 7–8, my emphases).
...
Clearly, programming involves exactly that kind of use of symbols. Or, as Abelson & Sussman put it in their introductory CS text (which we discussed in §3.14.4): A computational process is indeed much like a sorcerer’s idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, it is very real. It can perform intellectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory. *The programs we use to conjure processes are like a sorcerer’s spells.* They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform. (Abelson et al., 1996, my italics)
kykat
I always thought of myself as someone closer to a craftsman than an engineer, it's true that there's more "I think", "I believe" than verified working processes, their limits, etc.
But I also think that the software development process is maybe too flexible to be regulated, and tested like the other disciplines, a building is always a building, a material is always the same material.
But in software, who is going to test and verify the "materials" if they change constantly and evolve? It seems to me that any attempt at standardizing software development could slow down development so much that most won't find it to be worth it.
cwillu
A material is not always the same material, that's a non-trivial part of what engineering is about managing. Building to code is downstream of engineering, and that's more or less when you can get away with “SPF is SPF”, because the building code is already accounting for the differences in the safety margins and allowed/required techniques, vs the non-trivial difference between spruce, fir and pine.
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.
imglorp
This is closely related to why Sussman and Abelson stopped teaching SICP: it is not possible to engineer software any more because systems are too complicated to completely understand and abstractions hide too many behaviors. So now we do "programming by poking" to understand what the system does instead of making it correct by construction.
http://lambda-the-ultimate.org/node/5335
We just tinker. That's all we can do to get stuff done.
tptacek
Helps to have more of the quote:
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.
Marshferm
Which means software is trapped behind the evolutionary lens. And without a direct connection between goal and method, it's like an out of control path to extinction.
uvaursi
I’ll stick my neck out and say SICP has never been relevant to me. I’ve tinkered from embedded, to OS, to databases, to desktop applications, drivers, compilers, web applications, and all sorts of shit inbetween when I’m not reversing some archaic binary compiled in a pre-standard C++. I’ve done both idiomatic programming in a language as well as applying idioms from other languages that I liked. I’ve turned C# into Lisp because it couldn’t do what I needed it to do. I read through ARM opcode docs while I’m daydreaming of writing Ruby.
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.
api
There have been serious efforts at software engineering, like the OOP movement in the 1980s and 90s to construct software very methodically.
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.
spookie
Look at ECS and game dev. Some may say games are just products, yet some real engineering is done in some places.
porridgeraisin
> 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.
Interesting thought that. Makes a lot of sense. Will remember it the next time I randomly have a train of thought about software complexity on the bus... Am I normal? does everyone here do that? Of course outside hackernews this is a hopeless question.
hatsuseno
How many centuries did it take for civil engineering, for example, to become the codified, standardized, and respected calling it is now? While I'm sure "software development" will leapfrog that span of time, but it's only been 75 years since the discipline was invented to begin with (Lovelace's work was more applied math than anything else, but the starting point is arguably between then and, let's say, FORTRAN?).
That is to say, as a programmer, I feel like we're wading in an ocean of unknown size and depth. As we learn, by trial and error, the confines of that space will fuel the standardization and codification of the craft will only increase as a function of time until it isn't craft, but applied science.
Edit: s/applied science/engineering/
okaleniuk
Well, yes, but after the 75 years, don't you think that "too young" argument is getting old? Nuclear energy, medical imaging, and the space part of aerospace are all younger than "software development". These are all mature industries highly codified, and they also all also encompass software development among other things. Could it be that software development isn't an engineering discipline at all but a supporting activity?
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?
pxc
What is the reason for such optimism? My experience is that most people don't really attempt to write good code, and most employers even discourage it most of the time. And I'm just t as talking about basic correctness here— making sure it actually addresses all the requirements, making sure it actually handles all the possible states of cases it can encounter, etc.
efitz
Building software is usually a craftsmanship task.
Software can be engineered, but It’s rare and expensive so it’s only built that way when the cost is justified, as when building life critical systems (manned aircraft/spacecraft flight controllers) or security critical components like ssl stacks, cryptographic algorithm implementations, etc.
analog31
I wonder if there's a danger of comparing the real activity of programming with an idealized picture of engineering.
Most time spent by people with engineering degrees and job titles, is involved in things like organizing and arranging things, fitting things together, troubleshooting, documentation, meetings. Doing "hard" quantitative engineering is rare, and a lot of the calculations have been rolled into the CAD software. Unless designs are really critical, it's possible to solve problems by the rule of "when in doubt, make it stout."
Is this OK? I think it's an outgrowth of the rising complexity of products. As the number of pieces rises by O(n), the number of interactions goes as O(n*2), so at some point the dominant effort is managing interactions between pieces, rather than engineering the pieces.
BoppreH
I think this eternal discussion persists because we conflate two different aspects of software engineering: the technical and the social.
Technically, we're a mature discipline. The author laments our lack of tools as advanced as architectural CAD systems, but I'm unconvinced. We have static types, tests, linters, version control, benchmarks, standard data formats and protocols, deployment orchestration, debuggers. It's pretty nice.
Socially, our discipline feels immature. As mentioned, we don't know how well TDD works, how best to write documentation, or how to pick a flavor of agile. But these are meta-problems that plague every discipline! I challenge you to find a high quality study comparing imperial vs metric units in architecture, or the ideal number of architects for a given project size.
sota_pop
Engineer is to scientist as builder is to engineer.
Scientists take reality observations and make theories/models/principles. Engineers take scientific principles and make technological designs. Builders take available technologies and make a product/object/_thing_.
In each level, understanding how your inputs work defines the minimum criteria of success, but those who take the time to understand the “why” are largely considered “the good ones”.
And the rest is turtles all the way down.
karaterobot
Some programmers are engineers, but not all programmers are engineers. A lot of us are plumbers, basically. We connect together things other people have engineered. There's nothing wrong with plumbing; it's an important, honorable profession. It's just a different thing than engineering. And I'm not saying that a really good programmer transforms into an engineer by virtue of being really productive, or smart, or whatever—I'm saying engineering is a specific activity that most of us don't do every day as part of our jobs. So, to the point of this article, I'd like evidence to be gathered from engineers, specifically, and not programmers like me.
throwaway838112
[dead]
WillAdams
Sturgeon's Law.
For counter-examples see:
https://www-cs-faculty.stanford.edu/~knuth/taocp.html
and
https://www.youtube.com/watch?v=bmSAYlu0NcY
which is about the wonderful book:
https://www.goodreads.com/book/show/39996759-a-philosophy-of...
Most of software isn't engineering, it's just building.
It's like a lot of these custom car/motorcycle builders vs actual engineers designing for a major manufacturer. You are both building a product but one places a lot more rigor on the science, data, and testing behind the decisions. That doesn’t mean the custom builders don't build good stuff, just that you won't get answers to things like how much force a particular part can take or how much energy it will absorb in a crash.
In software, you might have some people still doing real software engineering, but they are in sectors that take documentation and testing more seriously. Not that every player takes this dedicated approach, but potentially parts of auto, aviation and defense fall into this.