9 ms·

Is Software the UFOlogy of Engineering Disciplines?

99 points by flail 11mo ago

Zigurd 11mo ago
It's craft. But what about the math, you say. All kinds of craft demand understanding of the related math.
- Marshferm 11mo ago
  The math serves the outcomes, not the other way around.
  - layer8 11mo ago
    That’s true for all natural sciences. That doesn’t make them mere craftsmanship. (Not to diminish good craftsmanship, which I highly value.)
    - Marshferm 11mo ago
      Philosophical truths, or empirical discoveries, demonstrations are not merely crafted, they are thresholds in and of themselves. The math is always separate from the theoretical leap. We may replace math eventually with a more precise system that is non-symbolic, non modeled.
- iberator 11mo ago
  DEULSION. For example sewing and archery doesn't need math as must have. Same with arabic calligraphy or painting.
pbarry25 11mo ago
Many governments do not recognize software development as an engineering discipline, and do not treat it (i.e. licensing, regulation) as such.
Marshferm 11mo ago
The binary was always a kind of hallucination from real events. It's a toy model that uniquely (and mostly poorly) fits in our reality as simula. This article demonstrates Baudrillard was more accurate than The Matrix, ie the simula becomes seamless and transparent in our reality. It's not separate. Software is neither engineering nor science, so the terms Software Engineering and Computer Science are mislabels at best and extinction propaganda at worst.
Almondsetat 11mo ago
What I believe makes the distinction between engineer and non-engineer in the software world so difficult to pin down is that software is so powerful that most non-engineers can end up easily doing engineer-level work. For example, a mechanical engineer is someone that designs mechanical systems. In order to do that, they will need specialized and very expensive equipment, and the end result will be produced with machines costing hundreds of thousands or even millions of dollars. Designing a system and producing a single one-off artifact are two very different things, and that's why a lone craftsman in their shed cannot do actual engineering (outside of pen and paper mockups). With software, otoh, it takes nothing to go from default nginx for serving your static personal website to an orchestrated cluster of containers and load balancers. The problem is that, for the latter, if you haven't got an engineer-like training, you will not be able to reason about the system, because you didn't really design it.
- giantg2 11mo ago
  "For example, a mechanical engineer is someone that designs mechanical systems. In order to do that, they will need specialized and very expensive equipment, and the end result will be produced with machines costing hundreds of thousands or even millions of dollars." 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.
  - Almondsetat 11mo ago
    Was the AK-47 first built and designed with stuff a normal mechanic would have had access to at the time? And to test it? And produce it at scale? That's engineering work.
giantg2 11mo ago
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.
- Marshferm 11mo ago
  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 11mo ago
    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 11mo ago
      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.
- 9rx 11mo ago
  > 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.
kykat 11mo ago
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 11mo ago
  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.
- beAbU 11mo ago
  I think there is space for both. 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.
jerf 11mo ago
This isn't an uncommon lament, despite what the author thinks. The problem is that running "studies" on what the author and others are asking for is effectively impossible. You can't get 25 teams of suitably-random professionals to build a non-trivial program one way, and 25 to build it another, and then do statistically-significant analysis of them, because that would be a staggeringly expensive study... and that is just for one such study, which would then be, you know, wrong, incorrectly analyzed, controversial, biased, etc. The expense of getting a representative set of such studies, independently conducted, enough to actually settle a question, beggars the imagination. Even such studies as have been performed are almost all invalidated by virtue of being run on inexperienced students. I'm not really that interested in whether inexperienced students do or do not do well with some methodology for the most part. What happens with professionals? In the meantime, all we've got is experiences. Contrary to popular belief, science does not mandate that we therefore curl up into a ball and cry ourselves to sleep at night. We just have to do our best. Berating other people for not pouring billions of dollars into the simplest of studies won't help much. They're still not going to, and you still have to go to work, sit down, and figure out how you're going to accomplish some task, even it you don't have double-blinded meta-analyses from decades of studies to pull from.
- Verdex 11mo ago
  This is so close to my sentiment that I had to double check to see if I wrote it. 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.)
hatsuseno 11mo ago
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/
- pxc 11mo ago
  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.
- okaleniuk 11mo ago
  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?
  - dingdongditchme 11mo ago
    https://en.wikipedia.org/wiki/ANSI_C https://en.wikipedia.org/wiki/ANSI_C, Software Engineering is also codified imho.
  - 11mo ago
karaterobot 11mo ago
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 11mo ago
  [dead]
apalmer 11mo ago
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.
- deleted 11mo ago
  [deleted]
- deleted 11mo ago
  [deleted]
- NitpickLawyer 11mo ago
  > 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 11mo ago
efitz 11mo ago
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.
sampo 11mo ago
> More than 20 years ago, I corresponded with famous UFO researcher Stanton T. Friedman. His central claim was that “the evidence is overwhelming that some UFOs are extraterrestrial spacecraft”. I don't believe in UFOs. But if I had to believe in UFOs, this would be my position: We have had modern humans for 500 000 years [1]. If it takes 10 000 years to make it from stone age to space age, we have theoretically had time to make that 50 times over. Maybe there was a previous version of a human civilization [2], then wiped out by ice ages or something, but a small number of highly advanced humans have survived and keep hiding from us. I think this could be somewhat more plausible than interstellar travel. [1] Or maybe 1 million https://news.ycombinator.com/item?id=45510582 https://news.ycombinator.com/item?id=45510582 [2] https://en.wikipedia.org/wiki/Silurian_hypothesis https://en.wikipedia.org/wiki/Silurian_hypothesis
- skeezyjefferson 11mo ago
  what do you think the cambrian explosion was
- Normal_gaussian 11mo ago
  The largest obstacle to this theory being taken seriously is the lack of evidence in long term records, such as ice cores. 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.
  - sampo 11mo ago
    > This is highly unlikely Absolutely. But are visitors from other star systems any less unlikely?
imglorp 11mo ago
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 http://lambda-the-ultimate.org/node/5335 We just tinker. That's all we can do to get stuff done.
- api 11mo ago
  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-Enterprise-Edition 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.
  - spookie 11mo ago
    Look at ECS and game dev. Some may say games are just products, yet some real engineering is done in some places.
z3t4 11mo ago
The thing with software is that you need to feel the pain in order to learn something. For example, when you lose all your work due to a bad HDD, you learn the importance of backups. But we also learn from others telling you that you need backups. So you make a copy of your data, but on the same hdd. Because you really haven't learned the lesson. Same with test driven development, you can have an entire career without software regression bugs, so you have no reason to use TDD. No pain no gain!
TedDallas 11mo ago
Ask this question in the 1940s and they would tell you it’s math. We are making machines that do math to kill Nazis. Now take this vacuum tube and plug it in over there and then go get me a cigarette.
1970-01-01 11mo ago
I've always wondered why UFOs are only a USA phenomenon. Why doesn't China have these extraterrestrial biological remains? What about Russia? North Korea? Japan? Because it's a form of mass-hysteria. Just like the flat Earth crowd, they will continue to shovel the narrative and ignore scientific evidence.
- 7thaccount 11mo ago
  If you ever want to see how they think, just check out the myriad UFO subreddits. It's pretty wild. 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.
  - IlikeKitties 11mo ago
    > 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. That's a pretty annoying sampling bias and doesn't reflect the community as a whole. There's plenty of rational voices that think most things are just balloons and drones, but they don't comment when it's boring and mundane. In those cases, only schizo voices remain.
    - 7thaccount 11mo ago
      Maybe. Pull up any one of hundreds of threads. Read through hundreds of comments and you'll have one or two people respond rationally and the rest is all folks saying that the aliens are harvesting our souls or something else equally insane like remote viewing. It just seems pretty lopsided to me, but yeah...maybe they're just a lot more vocal.
- krapp 11mo ago
  Mind you, I'm saying this as a hard skeptic only because this is a persistent but weak counterargument, and thus not very useful. 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.
uvaursi 11mo ago
Software development isn’t engineering and it has never been. Software developers aren’t engineers. I don’t know why this keeps coming up, maybe slow news day. It’s okay to be passionate about a craft or a job and for that job to be very technical and demanding. Many people feel that way about what they do, and they are perfectly okay not being engineers.
Devasta 11mo ago
Real engineers can face personal liability and even jail time for negligence. How much of modern software practices would exist today if the senior engineer needed to sign off on a project?
- BoxOfRain 11mo ago
  > Real engineers can face personal liability and even jail time for negligence. 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.
IlikeKitties 11mo ago
This is as much about UFOlogy as it's about SE. But there's also Science in Ufology, for example statistical analysis of reported UFO sightings or video analysis of UFO Videos. I think this applies to software engineering as well. Here's an example I found enlightening: It's about the HTTP3& the QUIC protocol: https://www.youtube.com/watch?v=4rYPXgCKamM https://www.youtube.com/watch?v=4rYPXgCKamM So much real engineering went into that, from fossilized infrastructure that doesn't allow certain ipv6 extension headers, to assumptions about the great firewall of china and it's inner workings and more.
1970-01-01 11mo ago
One big caveat to this is formal methods. If we did formal methods for all production code, it would meet the highest definition for rigor and rest safely as a true engineering discipline. https://en.wikipedia.org/wiki/Formal_methods https://en.wikipedia.org/wiki/Formal_methods
- skeezyjefferson 11mo ago
  this covers only the most technical fields that already specify things rigorously. most people arent technical enough to even understand what a formal spec is, so how do you deal with them? insist they learn formal methods?
  - layer8 11mo ago
    Most people aren’t software engineers, so it’s not clear why that should be a problem.
    - skeezyjefferson 11mo ago
      ...? because you have to deal with them? as in theyre paying you to write software. so now what? the idea falls apart when it meets reality
- mitthrowaway2 11mo ago
  I find it especially ironic that the engineering professional regulator in BC (EGBC), in their guidelines on software engineering, mention as a specific example that a software engineer might need to rely on the expertise of a non-software-engineer who has specialist skills such as (by their own example) formal software verification methods!
BoppreH 11mo ago
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.
- atmavatar 11mo ago
  > We have static types 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.
sota_pop 11mo ago
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.
WillAdams 11mo ago
Sturgeon's Law. For counter-examples see: https://www-cs-faculty.stanford.edu/~knuth/taocp.html https://www-cs-faculty.stanford.edu/~knuth/taocp.html and https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY which is about the wonderful book: https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design https://www.goodreads.com/book/show/39996759-a-philosophy-of...
okaleniuk 11mo ago
Is software an engineering discipline at all? There are plenty of activities that are essential for engineering but not a sort of engineering themselves. Like writing documentation, or communicating requirements to your colleagues. Making instructions and operational procedures. Management. Accounting. Marketing. What makes making software an engineering discipline and making coffee not? Where is the line and why we presume we should be behind that line?
Validark 11mo ago
I hate the idea of having one "Software Discipline". Something is lost when people are constrained by OOP or TDD or "Clean Code". Obviously, as with the example of TDD in the article, a lot of these terms mean different things to different people. Hence whenever "Clean Code" is criticized, people who think their code is "clean" take up arms. I tend to disagree with most of these rulesets that are meaningless to "engineering". The idea that a function should only be 40 lines long is offensive to me. Personally, I would rather have one 400 line function than ten 40 line functions. I'm a Ziguana. I care about handling edge cases and I think my programming language should be a domain specific language to produce optimal assembly. I would not constrain other people who feel differently. I read an article where some project transitioned from Rust to Zig, even though the people on the team were all Rustaceans. Obviously their Rust people hated this and left! To me, that's not a step in the right direction just because I prefer Zig to Rust! That's a disaster because you're taking away the way your team wants to build software. I think hardly any of the things we disagree on actually have much to do with "Engineering". We mostly aren't proving our code correct, nor defining all the bounds in which it should work. I personally tend to think in those terms and certain self-contained pieces of my software have these limits documented, but I'm not using tools that do this automatically yet. I'd love to build such tools in the coming years though. But there's always the problem that people build tools that don't notice common use-cases that are correct, and then people have to stop doing correct things that the tool can't understand.
Finnucane 11mo ago
It's a little bit of irony that the example of the author points to architects relying on a CAD system, a system that was presumably built by programmers. Who had to understand that the results their software produced had to have a high level of reliability--if it produced a wrong result, buildings could collapse, people could be hurt or killed. Errors would be extremely costly. So it's not impossible, just most software isn't held to that standard, because there's less incentive.
analog31 11mo ago
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.
shagie 11mo ago
I'm going to refer to Philosophy of Computer Science ( https://news.ycombinator.com/item?id=20912718 https://news.ycombinator.com/item?id=20912718 https://news.ycombinator.com/item?id=10388603 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) https://jpmens.net/2021/04/09/the-unix-magic-poster/ https://jpmens.net/2021/04/09/the-unix-magic-poster/ https://news.ycombinator.com/item?id=27029196 https://news.ycombinator.com/item?id=27029196
ipsento606 11mo ago
you don't even need a degree to be a software engineer, let alone any professional accreditation the idea that all, or even most, "software engineering" is real engineering is laughable
invalidOrTaken 11mo ago
man, if you want engineering guarantees, you're gonna have to pay for them, both in currency and realistic requirements.
alde 11mo ago
Huh, such a self-deprecating take on software engineering can only come from a software engineer. If the author spent more time with people working in other "real" engineering or science fields, he would know how much slop and lazy reasoning there is in there. For a visual confirmation, look at how much faulty and badly designed cars or house electrical appliances get released every year. Things which break after a couple weeks of use. Quality is rare everywhere, not just in SWE.
thenthenthen 11mo ago
Not sure what this is about but the conclusion doesnt seem to add up. Electronics and mechanical engineering is ‘neutral good’? Uh.. have you ever tried to interpret a signal from a sensor?
aranchelk 11mo ago
I’ve seen several of these discussions on HN, they’re never particularly illuminating. What always seems to missing: * Perspective of what it’s like working in other engineering disciplines. * A clear and shared definition of what “engineering” is. * Experiences shared by people who do apply significant math and science to their software authorship.
mikewarot 11mo ago
Electrical Engineering - The user sees an outlet, plugs in a lamp, and it works. If the lamp contains a short, the circuit breaker trips, everything else remains safe. Behind the scenes, a power grid, with protection every step of the way, all the way down to a home. If something goes wrong with a load, the circuit disconnects, protecting the wiring in the home, the user (in the case of ground faults), and in most cases, the load itself. --- Software "Engineering" - The user installs a program. They then run the program, Any bug can result in permanent ingress of control, exfiltration of data (bank accounts, email, personal information, etc), and the computer can be made permanently unsafe. All the authority of the user is supplied to every program they run. There are no equivalents to the protection system of the power grid, or circuit breakers. It's all patchwork fixes in layers of accumulated cruft. Real engineered solutions are possible. It's possible to make systems as user friendly and productive as we're used to, while keeping things safe.
- 9rx 11mo ago
  Safety is the concern of "professional engineering". "Engineering" is about designing systems — that may or may not be safe.
- jayd16 11mo ago
  The risk factors are really pretty different. Most software is run in a way that can't burn your house down. In that sense software is far more secure. Physical security is usually actually far easier to break than most software security systems but software ports are easier to hit from afar and en masse. You really can't compare these things.
Twey 11mo ago
The ‘three tribes of programming’ [1] strike again! This thread is full of claims that ‘programming is really engineering’ (in accordance with the article), ‘programming is really building’, or ‘programming is really philosophy/mathematics’. They're all true! It's not that one of them is the True Nature of software and anyone doing the others is doing it wrong or at a lower level. These are three different things that it is completely reasonable to want to do with software, and each of them can be done to an amateur or expert level. But only one of them is amenable to scientific analysis. (The other two are amenable to market testing and formal proof, respectively.) [1]: https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/
- Twey 11mo ago
  On second thought the tribal testing framework here is a bit simplistic, and there's some cross-tribe pollination, to varying levels of success. The ‘maker’ tribe also tests with HCI assessments like GOMS and other methods from the ‘soft’ sciences like psychology and sociology, not just economics/business science. Model-checking and complexity proofs (and complexity type systems) are mathematical attempts to apply mathematician-programmer methods to engineer-programmer properties. Cyclomatic complexity is an attempt to measure mathematician-programmer properties using engineer-programmer methods.
never_inline 11mo ago
I tend to evaluate how well engineered a system is based on these pillars. * Reliability - Includes HA, fault-tolerance on single node, reconciliation or reliable rollback of failed transactions, ability to manually intervene if something is wrong, and observability * Security - privilege separation and defense in depth * Performance - Are basic operations fast? Are there worst case performance pathologies? Are batch interfaces available for efficient processing? How many concurrent users can you handle (if server based). If we consider all these and perfectly implement, it's already pretty rigorous as an engineering discipline. I think companies at Google scale can do that, on projects with budget. But everywhere else, we make lots and lots of compromises. So there's it. For example, building high performance network systems or DB engines is more "engineering" than building line-of-business application. Because more of these "engineering" concerns are the part of specification. I am intentionally leaving out UX, because its a product design problem.
- deleted 11mo ago
  [deleted]
culebron21 11mo ago
In one particular matter software engineering has measurements -- performance. Lots of cross-language comparisons, before-after. Although, it's still not done where it should be -- e.g. when planning an architecture, sometimes I personally hear "in the cloud it will be different" and nothing else. In other areas, software engineering seems a lot like alchemy, ages before it became the serious science of chemistry.
n0um3n4 11mo ago
There are standards (and surely more to come), but I still wouldn’t call it engineering. Then again, I’m just a theoretical physicist who wandered into software development out of necessity, so treat that as a biased call. Sometimes I wonder: do people still believe a man's word? I do honor that. I have great respect for humans who give and follow their word. Sure, they make mistakes and you bet your butt they hold themselves accountable but... do people still do that? I’m honestly curious, because I do take people’s anecdotes seriously (keeping in mind that brains are fuzzy with perception and memory fills the gaps), and I still tend to take someone at their word. Lately I’m noticing how naive that is, and how much people take advantage of it. Why don’t we hold them accountable? Are we tolerating so much that we end up doing a kind of “peaceful violence”? I’m not calling for witch hunts or anything, but surely we can do better than whatever is happening now. Take the congressional hearing, for example: if there’s strong evidence someone lied, publicly we should at least be able to say, “Your statements are not credible for the time being.” How do you come back from that? I don’t know. Take YouTube videos nowadays: clickbait titles and exaggerated facial expressions in thumbnails just to grab attention. If the video doesn’t actually deliver on the premise of the title, it should be reported as misleading, regardless of the “this video was made for entertainment” disclaimer. That attitude is bleeding into so many areas of life. Language and words are becoming a joke, and over time people get used to it and copy the same behavior. I guess my point is: why is someone’s word no longer taken seriously (if it ever really was)? And why don’t we hold people accountable?
HeyLaughingBoy 11mo ago
Just going to leave this here: https://www.amazon.com/Safeware-Computers-Nancy-G-Leveson/dp/0201119722 https://www.amazon.com/Safeware-Computers-Nancy-G-Leveson/dp... Note that this book is 30 years old!
keeda 11mo ago
This seems to have been written by somebody who has no idea what other engineering disciplines look like. Note how TFA has, like, 10 words about other engineering disciplines and instead goes on and on about some stretched analogy to UFOlogy. Software engineering is absolutely an engineering discipline. Now, full disclosure so you can adjust your dosage of salt: My whole professional career has been in software development. However, my 4-year degree was in a branch of Electrical Engineering discipline (Process Control) and I have a handful of small “cottage” control systems and embedded projects under my belt. I also regularly follow other fields of engineering out of interest (communications, DSP, robotics.) But my biggest claim to non-software engineering fame is that as an intern, on my very first “real” project ever, I caused my very first outage, in which I brought down a factory. No, not an AbstractFactoryFactory; an actual factory producing actual copper tubes. It was supposed to run 24/7/365 and was down for at least a day and caused significant $$ losses and spawned a major incident report to the CEO. With my “credentials” out of the way, here’s how I define engineering: Engineering is the intersection of applied sciences, economics and business. The fundamental core of any engineering is applying the principles of your scientific discipline and empiricism to navigate an environment of imperfect, changing information by making reasonable, practical tradeoffs to build something useful within a given cost. You'll note software engineering matches this definition perfectly. Any lack of rigor you may notice is simply a function of the cost and economics involved. And any discussion of engineering that leaves out economics and cost is fundamentally flawed. As an example, medical software for radiation therapy machines have extremely stringent standards and controls because the potential cost is a literal human life. On the other hand your bog-standard CRUD To-Do app has negligible costs (and most likely correspondingly low revenue) and is just fine with negligible rigor. But if you’re writing code to be deployed in a large microservice deployment, you do want some tests, because the potential cost is lots of lost engineering hours and happiness when cascading failures set off pagers at 3am. Yes, we are winging it for the most part, because costs are so low. But so are other disciplines! The professor who taught us PID control systems was an industry veteran who walked us through a bunch of complicated math that I would not inflict on an LLM because that’s how you get SkyNet… and then said something like: “This theory is essential, but you should know that tuning PID controllers is a black art. There are just too many variables we cannot control, so experts basically tune the system in Production by trial and error.” And they have similar problems! Buggy, poorly documented libraries? An early life lesson in embedded engineering is “Check the errata” because datasheets are essentially marketing materials. Shifting requirements? That’s how civil engineers end up constructing a right-angled bridge (https://news.ycombinator.com/item?id=44522579 https://news.ycombinator.com/item?id=44522579) Again: The only reason software engineering seems less rigorous is because that’s how the economics work out. Maybe someone who is experienced in other forms of engineering as well as software can keep me honest. But don’t let anybody tell you software engineering is not a real engineering discipline.
amboar 11mo ago
As I haven't seen a link to it in the comments yet: A while back Hillel Wayne put some effort into resolving the question of "Is Software Engineering Real Engineering?" with the crossover project: https://www.hillelwayne.com/talks/crossover-project/ https://www.hillelwayne.com/talks/crossover-project/ The conclusion he drew was that there's less difference than you might expect between software development and "traditional" engineering disciplines and that it's reasonable to consider software engineering a real engineering discipline.
cadamsdotcom 11mo ago
We describe our processes and software products as having “security” or “reliability” or “high availability” but none of those are testable qualities, which is at the core of what the author is contending. “F = m x a” is testable. If it were found to be untrue in some circumstances we could reproduce that untruth - and maybe uncover some new physics. The measures I mentioned (security, reliability, high availability) don’t have clear failure points that multiple people can agree upon. Even if they did there’s nothing universal about those agreements therefore they have no value to a new project. There is however something in the “meta” because utter disasters of software projects are less common (as a percentage of the number of projects in the world) than they used to be. We are learning axioms like “use of memory safe programming languages reduces human errors and that leads to safer code.” There’s engineering, craftsmanship, and heuristics in every software engineering role. And all three exist in every project - sometimes even in every task! We would all love to say it’s one or the other but it’s both. Ok, when is it one and when is it the other? Sorry to say it but we can’t even draw a line between CRUD database fetching business apps, and engineering the database itself. There’s no line - it is fuzzy and depends on the constraints your project faces. Software engineering as we do it in 2025, is both UFOlogy and engineering. It’s one then it’s the other, at different times, with no clear distinction between the two. And sometimes a task you’re doing can even contain both types of work at once.
Mikhail_Edoshin 11mo ago
Engineering means lots of documentation. Catalogs of parts. "Red rubber balls", listing all the variations and properties. Standard forms of documentation. Need to describe a file format? Here is a prescribed way to do that. So yes, software is not engineering yet. I think the reason is that component interoperability problem remains unsolved. The aim of OOP was that; at least Brad Cox saw it this way. One of entries in his blog said something like "software product related to security should not provide security; it should provide tools to build a secure system".
j2kun 11mo ago
A more measured and principled take: https://www.hillelwayne.com/talks/crossover-project/ https://www.hillelwayne.com/talks/crossover-project/

99 points by flail 11mo ago

Zigurd 11mo ago

It's craft. But what about the math, you say. All kinds of craft demand understanding of the related math.

Marshferm 11mo ago
The math serves the outcomes, not the other way around.
- layer8 11mo ago
  That’s true for all natural sciences. That doesn’t make them mere craftsmanship. (Not to diminish good craftsmanship, which I highly value.)
  - Marshferm 11mo ago
    Philosophical truths, or empirical discoveries, demonstrations are not merely crafted, they are thresholds in and of themselves. The math is always separate from the theoretical leap. We may replace math eventually with a more precise system that is non-symbolic, non modeled.
iberator 11mo ago
DEULSION. For example sewing and archery doesn't need math as must have. Same with arabic calligraphy or painting.

pbarry25 11mo ago

Many governments do not recognize software development as an engineering discipline, and do not treat it (i.e. licensing, regulation) as such.

Marshferm 11mo ago

The binary was always a kind of hallucination from real events. It's a toy model that uniquely (and mostly poorly) fits in our reality as simula. This article demonstrates Baudrillard was more accurate than The Matrix, ie the simula becomes seamless and transparent in our reality. It's not separate. Software is neither engineering nor science, so the terms Software Engineering and Computer Science are mislabels at best and extinction propaganda at worst.

Almondsetat 11mo ago

What I believe makes the distinction between engineer and non-engineer in the software world so difficult to pin down is that software is so powerful that most non-engineers can end up easily doing engineer-level work. For example, a mechanical engineer is someone that designs mechanical systems. In order to do that, they will need specialized and very expensive equipment, and the end result will be produced with machines costing hundreds of thousands or even millions of dollars. Designing a system and producing a single one-off artifact are two very different things, and that's why a lone craftsman in their shed cannot do actual engineering (outside of pen and paper mockups). With software, otoh, it takes nothing to go from default nginx for serving your static personal website to an orchestrated cluster of containers and load balancers. The problem is that, for the latter, if you haven't got an engineer-like training, you will not be able to reason about the system, because you didn't really design it.

giantg2 11mo ago
"For example, a mechanical engineer is someone that designs mechanical systems. In order to do that, they will need specialized and very expensive equipment, and the end result will be produced with machines costing hundreds of thousands or even millions of dollars." 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.
- Almondsetat 11mo ago
  Was the AK-47 first built and designed with stuff a normal mechanic would have had access to at the time? And to test it? And produce it at scale? That's engineering work.

giantg2 11mo ago

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.

Marshferm 11mo ago
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 11mo ago
  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 11mo ago
    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.
9rx 11mo ago
> 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.

kykat 11mo ago

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 11mo ago
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.
beAbU 11mo ago
I think there is space for both. 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.

jerf 11mo ago

This isn't an uncommon lament, despite what the author thinks. The problem is that running "studies" on what the author and others are asking for is effectively impossible. You can't get 25 teams of suitably-random professionals to build a non-trivial program one way, and 25 to build it another, and then do statistically-significant analysis of them, because that would be a staggeringly expensive study... and that is just for one such study, which would then be, you know, wrong, incorrectly analyzed, controversial, biased, etc. The expense of getting a representative set of such studies, independently conducted, enough to actually settle a question, beggars the imagination. Even such studies as have been performed are almost all invalidated by virtue of being run on inexperienced students. I'm not really that interested in whether inexperienced students do or do not do well with some methodology for the most part. What happens with professionals? In the meantime, all we've got is experiences. Contrary to popular belief, science does not mandate that we therefore curl up into a ball and cry ourselves to sleep at night. We just have to do our best. Berating other people for not pouring billions of dollars into the simplest of studies won't help much. They're still not going to, and you still have to go to work, sit down, and figure out how you're going to accomplish some task, even it you don't have double-blinded meta-analyses from decades of studies to pull from.

Verdex 11mo ago
This is so close to my sentiment that I had to double check to see if I wrote it. 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.)

hatsuseno 11mo ago

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/

pxc 11mo ago
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.
okaleniuk 11mo ago
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?
- dingdongditchme 11mo ago
  https://en.wikipedia.org/wiki/ANSI_C https://en.wikipedia.org/wiki/ANSI_C, Software Engineering is also codified imho.
- 11mo ago

karaterobot 11mo ago

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 11mo ago
[dead]

apalmer 11mo ago

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.

deleted 11mo ago
[deleted]
deleted 11mo ago
[deleted]
NitpickLawyer 11mo ago
> 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 11mo ago

efitz 11mo ago

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.

sampo 11mo ago

> More than 20 years ago, I corresponded with famous UFO researcher Stanton T. Friedman. His central claim was that “the evidence is overwhelming that some UFOs are extraterrestrial spacecraft”. I don't believe in UFOs. But if I had to believe in UFOs, this would be my position: We have had modern humans for 500 000 years [1]. If it takes 10 000 years to make it from stone age to space age, we have theoretically had time to make that 50 times over. Maybe there was a previous version of a human civilization [2], then wiped out by ice ages or something, but a small number of highly advanced humans have survived and keep hiding from us. I think this could be somewhat more plausible than interstellar travel. [1] Or maybe 1 million https://news.ycombinator.com/item?id=45510582 https://news.ycombinator.com/item?id=45510582 [2] https://en.wikipedia.org/wiki/Silurian_hypothesis https://en.wikipedia.org/wiki/Silurian_hypothesis

skeezyjefferson 11mo ago
what do you think the cambrian explosion was
Normal_gaussian 11mo ago
The largest obstacle to this theory being taken seriously is the lack of evidence in long term records, such as ice cores. 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.
- sampo 11mo ago
  > This is highly unlikely Absolutely. But are visitors from other star systems any less unlikely?

imglorp 11mo ago

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 http://lambda-the-ultimate.org/node/5335 We just tinker. That's all we can do to get stuff done.

api 11mo ago
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-Enterprise-Edition 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.
- spookie 11mo ago
  Look at ECS and game dev. Some may say games are just products, yet some real engineering is done in some places.

z3t4 11mo ago

The thing with software is that you need to feel the pain in order to learn something. For example, when you lose all your work due to a bad HDD, you learn the importance of backups. But we also learn from others telling you that you need backups. So you make a copy of your data, but on the same hdd. Because you really haven't learned the lesson. Same with test driven development, you can have an entire career without software regression bugs, so you have no reason to use TDD. No pain no gain!

TedDallas 11mo ago

Ask this question in the 1940s and they would tell you it’s math. We are making machines that do math to kill Nazis. Now take this vacuum tube and plug it in over there and then go get me a cigarette.

1970-01-01 11mo ago

I've always wondered why UFOs are only a USA phenomenon. Why doesn't China have these extraterrestrial biological remains? What about Russia? North Korea? Japan? Because it's a form of mass-hysteria. Just like the flat Earth crowd, they will continue to shovel the narrative and ignore scientific evidence.

7thaccount 11mo ago
If you ever want to see how they think, just check out the myriad UFO subreddits. It's pretty wild. 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.
- IlikeKitties 11mo ago
  > 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. That's a pretty annoying sampling bias and doesn't reflect the community as a whole. There's plenty of rational voices that think most things are just balloons and drones, but they don't comment when it's boring and mundane. In those cases, only schizo voices remain.
  - 7thaccount 11mo ago
    Maybe. Pull up any one of hundreds of threads. Read through hundreds of comments and you'll have one or two people respond rationally and the rest is all folks saying that the aliens are harvesting our souls or something else equally insane like remote viewing. It just seems pretty lopsided to me, but yeah...maybe they're just a lot more vocal.
krapp 11mo ago
Mind you, I'm saying this as a hard skeptic only because this is a persistent but weak counterargument, and thus not very useful. 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.

uvaursi 11mo ago

Software development isn’t engineering and it has never been. Software developers aren’t engineers. I don’t know why this keeps coming up, maybe slow news day. It’s okay to be passionate about a craft or a job and for that job to be very technical and demanding. Many people feel that way about what they do, and they are perfectly okay not being engineers.

Devasta 11mo ago

Real engineers can face personal liability and even jail time for negligence. How much of modern software practices would exist today if the senior engineer needed to sign off on a project?

BoxOfRain 11mo ago
> Real engineers can face personal liability and even jail time for negligence. 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.

IlikeKitties 11mo ago

This is as much about UFOlogy as it's about SE. But there's also Science in Ufology, for example statistical analysis of reported UFO sightings or video analysis of UFO Videos. I think this applies to software engineering as well. Here's an example I found enlightening: It's about the HTTP3& the QUIC protocol: https://www.youtube.com/watch?v=4rYPXgCKamM https://www.youtube.com/watch?v=4rYPXgCKamM So much real engineering went into that, from fossilized infrastructure that doesn't allow certain ipv6 extension headers, to assumptions about the great firewall of china and it's inner workings and more.

1970-01-01 11mo ago

One big caveat to this is formal methods. If we did formal methods for all production code, it would meet the highest definition for rigor and rest safely as a true engineering discipline. https://en.wikipedia.org/wiki/Formal_methods https://en.wikipedia.org/wiki/Formal_methods

skeezyjefferson 11mo ago
this covers only the most technical fields that already specify things rigorously. most people arent technical enough to even understand what a formal spec is, so how do you deal with them? insist they learn formal methods?
- layer8 11mo ago
  Most people aren’t software engineers, so it’s not clear why that should be a problem.
  - skeezyjefferson 11mo ago
    ...? because you have to deal with them? as in theyre paying you to write software. so now what? the idea falls apart when it meets reality
mitthrowaway2 11mo ago
I find it especially ironic that the engineering professional regulator in BC (EGBC), in their guidelines on software engineering, mention as a specific example that a software engineer might need to rely on the expertise of a non-software-engineer who has specialist skills such as (by their own example) formal software verification methods!

BoppreH 11mo ago

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.

atmavatar 11mo ago
> We have static types 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.

sota_pop 11mo ago

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.

WillAdams 11mo ago

Sturgeon's Law. For counter-examples see: https://www-cs-faculty.stanford.edu/~knuth/taocp.html https://www-cs-faculty.stanford.edu/~knuth/taocp.html and https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY which is about the wonderful book: https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design https://www.goodreads.com/book/show/39996759-a-philosophy-of...

okaleniuk 11mo ago

Is software an engineering discipline at all? There are plenty of activities that are essential for engineering but not a sort of engineering themselves. Like writing documentation, or communicating requirements to your colleagues. Making instructions and operational procedures. Management. Accounting. Marketing. What makes making software an engineering discipline and making coffee not? Where is the line and why we presume we should be behind that line?

Validark 11mo ago

I hate the idea of having one "Software Discipline". Something is lost when people are constrained by OOP or TDD or "Clean Code". Obviously, as with the example of TDD in the article, a lot of these terms mean different things to different people. Hence whenever "Clean Code" is criticized, people who think their code is "clean" take up arms. I tend to disagree with most of these rulesets that are meaningless to "engineering". The idea that a function should only be 40 lines long is offensive to me. Personally, I would rather have one 400 line function than ten 40 line functions. I'm a Ziguana. I care about handling edge cases and I think my programming language should be a domain specific language to produce optimal assembly. I would not constrain other people who feel differently. I read an article where some project transitioned from Rust to Zig, even though the people on the team were all Rustaceans. Obviously their Rust people hated this and left! To me, that's not a step in the right direction just because I prefer Zig to Rust! That's a disaster because you're taking away the way your team wants to build software. I think hardly any of the things we disagree on actually have much to do with "Engineering". We mostly aren't proving our code correct, nor defining all the bounds in which it should work. I personally tend to think in those terms and certain self-contained pieces of my software have these limits documented, but I'm not using tools that do this automatically yet. I'd love to build such tools in the coming years though. But there's always the problem that people build tools that don't notice common use-cases that are correct, and then people have to stop doing correct things that the tool can't understand.

Finnucane 11mo ago

It's a little bit of irony that the example of the author points to architects relying on a CAD system, a system that was presumably built by programmers. Who had to understand that the results their software produced had to have a high level of reliability--if it produced a wrong result, buildings could collapse, people could be hurt or killed. Errors would be extremely costly. So it's not impossible, just most software isn't held to that standard, because there's less incentive.

analog31 11mo ago

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.

shagie 11mo ago

I'm going to refer to Philosophy of Computer Science ( https://news.ycombinator.com/item?id=20912718 https://news.ycombinator.com/item?id=20912718 https://news.ycombinator.com/item?id=10388603 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) https://jpmens.net/2021/04/09/the-unix-magic-poster/ https://jpmens.net/2021/04/09/the-unix-magic-poster/ https://news.ycombinator.com/item?id=27029196 https://news.ycombinator.com/item?id=27029196

ipsento606 11mo ago

you don't even need a degree to be a software engineer, let alone any professional accreditation the idea that all, or even most, "software engineering" is real engineering is laughable

invalidOrTaken 11mo ago

man, if you want engineering guarantees, you're gonna have to pay for them, both in currency and realistic requirements.

alde 11mo ago

Huh, such a self-deprecating take on software engineering can only come from a software engineer. If the author spent more time with people working in other "real" engineering or science fields, he would know how much slop and lazy reasoning there is in there. For a visual confirmation, look at how much faulty and badly designed cars or house electrical appliances get released every year. Things which break after a couple weeks of use. Quality is rare everywhere, not just in SWE.

thenthenthen 11mo ago

Not sure what this is about but the conclusion doesnt seem to add up. Electronics and mechanical engineering is ‘neutral good’? Uh.. have you ever tried to interpret a signal from a sensor?

aranchelk 11mo ago

I’ve seen several of these discussions on HN, they’re never particularly illuminating. What always seems to missing: * Perspective of what it’s like working in other engineering disciplines. * A clear and shared definition of what “engineering” is. * Experiences shared by people who do apply significant math and science to their software authorship.

mikewarot 11mo ago

Electrical Engineering - The user sees an outlet, plugs in a lamp, and it works. If the lamp contains a short, the circuit breaker trips, everything else remains safe. Behind the scenes, a power grid, with protection every step of the way, all the way down to a home. If something goes wrong with a load, the circuit disconnects, protecting the wiring in the home, the user (in the case of ground faults), and in most cases, the load itself. --- Software "Engineering" - The user installs a program. They then run the program, Any bug can result in permanent ingress of control, exfiltration of data (bank accounts, email, personal information, etc), and the computer can be made permanently unsafe. All the authority of the user is supplied to every program they run. There are no equivalents to the protection system of the power grid, or circuit breakers. It's all patchwork fixes in layers of accumulated cruft. Real engineered solutions are possible. It's possible to make systems as user friendly and productive as we're used to, while keeping things safe.

9rx 11mo ago
Safety is the concern of "professional engineering". "Engineering" is about designing systems — that may or may not be safe.
jayd16 11mo ago
The risk factors are really pretty different. Most software is run in a way that can't burn your house down. In that sense software is far more secure. Physical security is usually actually far easier to break than most software security systems but software ports are easier to hit from afar and en masse. You really can't compare these things.

Twey 11mo ago

The ‘three tribes of programming’ [1] strike again! This thread is full of claims that ‘programming is really engineering’ (in accordance with the article), ‘programming is really building’, or ‘programming is really philosophy/mathematics’. They're all true! It's not that one of them is the True Nature of software and anyone doing the others is doing it wrong or at a lower level. These are three different things that it is completely reasonable to want to do with software, and each of them can be done to an amateur or expert level. But only one of them is amenable to scientific analysis. (The other two are amenable to market testing and formal proof, respectively.) [1]: https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/

Twey 11mo ago
On second thought the tribal testing framework here is a bit simplistic, and there's some cross-tribe pollination, to varying levels of success. The ‘maker’ tribe also tests with HCI assessments like GOMS and other methods from the ‘soft’ sciences like psychology and sociology, not just economics/business science. Model-checking and complexity proofs (and complexity type systems) are mathematical attempts to apply mathematician-programmer methods to engineer-programmer properties. Cyclomatic complexity is an attempt to measure mathematician-programmer properties using engineer-programmer methods.

never_inline 11mo ago

I tend to evaluate how well engineered a system is based on these pillars. * Reliability - Includes HA, fault-tolerance on single node, reconciliation or reliable rollback of failed transactions, ability to manually intervene if something is wrong, and observability * Security - privilege separation and defense in depth * Performance - Are basic operations fast? Are there worst case performance pathologies? Are batch interfaces available for efficient processing? How many concurrent users can you handle (if server based). If we consider all these and perfectly implement, it's already pretty rigorous as an engineering discipline. I think companies at Google scale can do that, on projects with budget. But everywhere else, we make lots and lots of compromises. So there's it. For example, building high performance network systems or DB engines is more "engineering" than building line-of-business application. Because more of these "engineering" concerns are the part of specification. I am intentionally leaving out UX, because its a product design problem.

deleted 11mo ago
[deleted]

culebron21 11mo ago

In one particular matter software engineering has measurements -- performance. Lots of cross-language comparisons, before-after. Although, it's still not done where it should be -- e.g. when planning an architecture, sometimes I personally hear "in the cloud it will be different" and nothing else. In other areas, software engineering seems a lot like alchemy, ages before it became the serious science of chemistry.

n0um3n4 11mo ago

There are standards (and surely more to come), but I still wouldn’t call it engineering. Then again, I’m just a theoretical physicist who wandered into software development out of necessity, so treat that as a biased call. Sometimes I wonder: do people still believe a man's word? I do honor that. I have great respect for humans who give and follow their word. Sure, they make mistakes and you bet your butt they hold themselves accountable but... do people still do that? I’m honestly curious, because I do take people’s anecdotes seriously (keeping in mind that brains are fuzzy with perception and memory fills the gaps), and I still tend to take someone at their word. Lately I’m noticing how naive that is, and how much people take advantage of it. Why don’t we hold them accountable? Are we tolerating so much that we end up doing a kind of “peaceful violence”? I’m not calling for witch hunts or anything, but surely we can do better than whatever is happening now. Take the congressional hearing, for example: if there’s strong evidence someone lied, publicly we should at least be able to say, “Your statements are not credible for the time being.” How do you come back from that? I don’t know. Take YouTube videos nowadays: clickbait titles and exaggerated facial expressions in thumbnails just to grab attention. If the video doesn’t actually deliver on the premise of the title, it should be reported as misleading, regardless of the “this video was made for entertainment” disclaimer. That attitude is bleeding into so many areas of life. Language and words are becoming a joke, and over time people get used to it and copy the same behavior. I guess my point is: why is someone’s word no longer taken seriously (if it ever really was)? And why don’t we hold people accountable?

HeyLaughingBoy 11mo ago

Just going to leave this here: https://www.amazon.com/Safeware-Computers-Nancy-G-Leveson/dp/0201119722 https://www.amazon.com/Safeware-Computers-Nancy-G-Leveson/dp... Note that this book is 30 years old!

keeda 11mo ago

This seems to have been written by somebody who has no idea what other engineering disciplines look like. Note how TFA has, like, 10 words about other engineering disciplines and instead goes on and on about some stretched analogy to UFOlogy. Software engineering is absolutely an engineering discipline. Now, full disclosure so you can adjust your dosage of salt: My whole professional career has been in software development. However, my 4-year degree was in a branch of Electrical Engineering discipline (Process Control) and I have a handful of small “cottage” control systems and embedded projects under my belt. I also regularly follow other fields of engineering out of interest (communications, DSP, robotics.) But my biggest claim to non-software engineering fame is that as an intern, on my very first “real” project ever, I caused my very first outage, in which I brought down a factory. No, not an AbstractFactoryFactory; an actual factory producing actual copper tubes. It was supposed to run 24/7/365 and was down for at least a day and caused significant $$ losses and spawned a major incident report to the CEO. With my “credentials” out of the way, here’s how I define engineering: Engineering is the intersection of applied sciences, economics and business. The fundamental core of any engineering is applying the principles of your scientific discipline and empiricism to navigate an environment of imperfect, changing information by making reasonable, practical tradeoffs to build something useful within a given cost. You'll note software engineering matches this definition perfectly. Any lack of rigor you may notice is simply a function of the cost and economics involved. And any discussion of engineering that leaves out economics and cost is fundamentally flawed. As an example, medical software for radiation therapy machines have extremely stringent standards and controls because the potential cost is a literal human life. On the other hand your bog-standard CRUD To-Do app has negligible costs (and most likely correspondingly low revenue) and is just fine with negligible rigor. But if you’re writing code to be deployed in a large microservice deployment, you do want some tests, because the potential cost is lots of lost engineering hours and happiness when cascading failures set off pagers at 3am. Yes, we are winging it for the most part, because costs are so low. But so are other disciplines! The professor who taught us PID control systems was an industry veteran who walked us through a bunch of complicated math that I would not inflict on an LLM because that’s how you get SkyNet… and then said something like: “This theory is essential, but you should know that tuning PID controllers is a black art. There are just too many variables we cannot control, so experts basically tune the system in Production by trial and error.” And they have similar problems! Buggy, poorly documented libraries? An early life lesson in embedded engineering is “Check the errata” because datasheets are essentially marketing materials. Shifting requirements? That’s how civil engineers end up constructing a right-angled bridge (https://news.ycombinator.com/item?id=44522579 https://news.ycombinator.com/item?id=44522579) Again: The only reason software engineering seems less rigorous is because that’s how the economics work out. Maybe someone who is experienced in other forms of engineering as well as software can keep me honest. But don’t let anybody tell you software engineering is not a real engineering discipline.

amboar 11mo ago

As I haven't seen a link to it in the comments yet: A while back Hillel Wayne put some effort into resolving the question of "Is Software Engineering Real Engineering?" with the crossover project: https://www.hillelwayne.com/talks/crossover-project/ https://www.hillelwayne.com/talks/crossover-project/ The conclusion he drew was that there's less difference than you might expect between software development and "traditional" engineering disciplines and that it's reasonable to consider software engineering a real engineering discipline.

cadamsdotcom 11mo ago

We describe our processes and software products as having “security” or “reliability” or “high availability” but none of those are testable qualities, which is at the core of what the author is contending. “F = m x a” is testable. If it were found to be untrue in some circumstances we could reproduce that untruth - and maybe uncover some new physics. The measures I mentioned (security, reliability, high availability) don’t have clear failure points that multiple people can agree upon. Even if they did there’s nothing universal about those agreements therefore they have no value to a new project. There is however something in the “meta” because utter disasters of software projects are less common (as a percentage of the number of projects in the world) than they used to be. We are learning axioms like “use of memory safe programming languages reduces human errors and that leads to safer code.” There’s engineering, craftsmanship, and heuristics in every software engineering role. And all three exist in every project - sometimes even in every task! We would all love to say it’s one or the other but it’s both. Ok, when is it one and when is it the other? Sorry to say it but we can’t even draw a line between CRUD database fetching business apps, and engineering the database itself. There’s no line - it is fuzzy and depends on the constraints your project faces. Software engineering as we do it in 2025, is both UFOlogy and engineering. It’s one then it’s the other, at different times, with no clear distinction between the two. And sometimes a task you’re doing can even contain both types of work at once.

Mikhail_Edoshin 11mo ago

Engineering means lots of documentation. Catalogs of parts. "Red rubber balls", listing all the variations and properties. Standard forms of documentation. Need to describe a file format? Here is a prescribed way to do that. So yes, software is not engineering yet. I think the reason is that component interoperability problem remains unsolved. The aim of OOP was that; at least Brad Cox saw it this way. One of entries in his blog said something like "software product related to security should not provide security; it should provide tools to build a secure system".

j2kun 11mo ago

A more measured and principled take: https://www.hillelwayne.com/talks/crossover-project/ https://www.hillelwayne.com/talks/crossover-project/