[HN Gopher] Is Software the UFOlogy of Engineering Disciplines?
___________________________________________________________________
Is Software the UFOlogy of Engineering Disciplines?
Author : flail
Score : 94 points
Date : 2025-11-07 13:09 UTC (9 hours ago)
(HTM) web link (codemanship.wordpress.com)
(TXT) w3m dump (codemanship.wordpress.com)
| Zigurd wrote:
| It's craft. But what about the math, you say. All kinds of craft
| demand understanding of the related math.
| Marshferm wrote:
| The math serves the outcomes, not the other way around.
| layer8 wrote:
| That's true for all natural sciences. That doesn't make them
| mere craftsmanship.
|
| (Not to diminish good craftsmanship, which I highly value.)
| Marshferm wrote:
| 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 wrote:
| DEULSION. For example sewing and archery doesn't need math as
| must have. Same with arabic calligraphy or painting.
| pbarry25 wrote:
| Many governments do not recognize software development as an
| engineering discipline, and do not treat it (i.e. licensing,
| regulation) as such.
| Marshferm wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| Depends on what you consider a normal mechanic. A hydraulic
| press, drills, and an engine lathe could be in a mechanic
| shop. At the very least, having those items doesn't make
| the mechanic an engineer.
| giantg2 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| _> 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.
| HPsquared wrote:
| A house comprises many parts. A custom motorcycle has many
| parts. These things are designed and built to established
| practices, but in 99% of cases they aren't really
| "engineered" with calculations and formalised decision-making
| processes and the like.
| 9rx wrote:
| _> A house comprises many parts. A custom motorcycle has
| many parts._
|
| Hence why they are engineered. I suspect you mentioned
| houses because the people who build houses are often
| referred to as builders, but that is because the people
| working houses often only do work on a single component.
| The system as a whole is referred to as engineering,
| though.
|
| _> with calculations and formalised decision-making
| processes and the like._
|
| You too seem to be confusing "engineering" with
| "professional engineering". While societies of professional
| engineers would like people to think that engineering is
| defined by mathematical and scientific rigour, that's not
| how anyone actually uses the term in practice. The
| "software engineering" label wouldn't exist if they did.
| HPsquared wrote:
| There is definitely some engineering that goes on in the
| software world, but it's mostly construction.
| 9rx wrote:
| While there is construction involved in software, the
| computer does that work. There is no human analog there.
| The human end of software is entirely at the design
| level, which is the defining characteristic of
| engineering -- so long as it is a system being designed,
| of course, which virtually all software is.
| hollerith wrote:
| Software development is more like drawing up the
| blueprints for a building than it is like working with
| materials made of atoms. (The analog in software to the
| construction phase of the creation of a physical building
| either does not exist or proceeds very quickly, is very
| unlikely to fail or be delayed and is almost completely
| automated.)
|
| The word "patterns" a la software patterns was taken
| directly from the writings of an architect of physical
| buildings (namely Christopher Alexander). It is not an
| accident that it was not taken from the work of a
| construction worker, not even a high-level one in charge
| of hiring subcontractors and of years-long billion-dollar
| construction projects.
|
| The most salient difference between blueprints and
| software artifacts is the sheer complexity of software
| artifacts these days (which is why there aren't
| organizations that employ many tens of thousands of
| draftsmen and architects of physical structures) but that
| is a difference in degree, not a difference in kind.
| 7thaccount wrote:
| Thanks for bringing up the PE distinction. This kind of
| argument comes up here ad nauseum. People have different
| views and we argue semantics.
|
| There is engineering as a discipline (e.g., mechanical,
| electrical, industrial, civil, aerospace...etc.) and
| engineering in a more colloquial sense like "I did some
| hillbilly engineering and rigged up a pea sheller". Both
| involve solving problems.
|
| The former typically involves the person going through a
| rigorous 4-5 year program where they take a bunch of advanced
| math and physics classes and a ton of other classes
| (including coding and robotics as well as more specific
| classes such as power electronics) that teach logical
| thinking and problem solving. I'm always amazed that I can
| more or less talk to any engineer across the country
| (different state, different university, different engineering
| discipline) and still recognize their training and that hyper
| analytical mindset and feel the kinship. That of course
| doesn't mean that there aren't similar analytical people that
| went in other directions, but the training is a real thing.
|
| A professional engineer passed their fundamentals of
| engineering exam, got their degree, and then took their
| professional engineering exam. You used to have to get 4
| years of work experience before applying, but I think they
| got rid of that. It's an awful 8-hour exam with a pretty low
| pass rate. Honestly though, the PE usually just means the
| engineer was willing to spend 3-6 months prepping for the
| exam and has a need for the license to stamp papers. A lot of
| engineers never get it if they don't need it. I believe you
| need it in some cases for court cases.
|
| As far as software engineering goes. It seems to be a
| discipline that matches the second colloquial definition more
| in a lot of cases. In some cases they have actual software
| engineering degrees where the student takes all the standard
| intro engineering courses (calculus, linear algebra,
| statistics, differential equations, statics, dynamics,
| circuits, thermodynamics) before doing the core classes
| distinct to that major. In that case, I'd call them an
| engineer due to the training and think it's an appropriate
| job title even if they get a job slinging corporate java,
| which would not typically be viewed as traditional
| engineering. So they're an engineer...not necessarily doing
| engineering. Does that really make sense? My own definition
| breaks down if we apply this to the same engineer becoming a
| garbage man. They're still an engineer by training, but
| they're most definitely not doing engineering anymore.
|
| Also, if Pete gets a job slinging code out of highschool...we
| can say he's doing engineering in the colloquial second
| sense, but is he an engineer in the first sense? No.
|
| Clear as mud? As an engineer I now must flog myself for my
| own internal inconsistencies. In all seriousness, language is
| hard and sometimes imprecise. I didn't realize my rambling
| got so long and apologize.
| gosub100 wrote:
| Then you get paradoxes like why the rigor doesn't work in
| practice. These expensive CS books mathematically _prove_ a map
| has faster access than a vector because it uses a binary tree.
| Yet the vector works faster because the CPU pipelines
| sequential operations very efficiently.
| layer8 wrote:
| CS proves that a binary tree is faster _asymptotically_ , and
| that's still true and very much of practical relevance
| regardless of the CPU you use.
| auggierose wrote:
| No, they don't. A vector has faster access than a binary
| tree, O(1) vs. O(log n). Maybe read some of those expensive
| books.
|
| If you talk about editing the data structure, then it
| depends.
| amelius wrote:
| Most of software is just plumbing.
| HPsquared wrote:
| And plumbing is a highly skilled and essential profession.
| And a lot of plumbing work involves engineering to a greater
| or lesser extent.
| amelius wrote:
| That's because AI cannot do physical things yet very well.
| gchamonlive wrote:
| It's solving and building, but most of all it's language. It's
| all language. Either telling the machine what to do or
| coordinating a group of people cohesively.
| ratelimitsteve wrote:
| I actually read an interesting study, probably here, about
| software engineers. It turns out that for as much emphasis as
| we put on mathematics we actually tend to be better at
| language, and that even our penchant for maths is less in the
| way of calculation and more in the way of definition and
| expression (which is to say, making it the language numbers
| speak and learning it that way).
| sam_lowry_ wrote:
| It would be nice to have a reference.
| gchamonlive wrote:
| This one perhaps?
|
| https://www.washington.edu/news/2020/03/02/not-a-math-
| person...
| HPsquared wrote:
| That's where engineering fits in. It's in the knowledge and
| information space, you make things like plans, arguments,
| decisions, documents.
|
| That's not to say it all needs to be written down; someone
| can do the "engineering" of a small project all in their own
| head and then implement it themselves.
|
| The engineering process itself is a form of knowledge work. A
| single person can do both tasks of course.
| cachius wrote:
| You mean communication, the transfer of ideas. Already hard
| between humans, machine language and operation is completely
| foreign.
| gchamonlive wrote:
| No, I mean language. Even if you are alone with yourself in
| a solo project, you need language to structure your ideas.
| Communication is when you need to transfer these structures
| in place (you and a team) and/or in time (you and yourself
| in different points in time). But it's first and foremost a
| problem of language, of giving structure to reality.
| reedlaw wrote:
| Agreed, in the sense that software development is an iterative
| process of trial and error similar to custom car building. But
| software isn't like a car. It's more like a car factory. It
| should produce something of value repeatedly.
| kykat wrote:
| 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 wrote:
| 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 wrote:
| 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.
| empath75 wrote:
| Any definition of engineering which excludes the Wright
| brothers and James Watt, who _invented the machine that gives
| the field it's name_ is a fairly poor definition. If you're
| creating something in a poorly understood situation by
| applying rules of thumb, you're doing engineering. Depending
| on what you are doing, flying by the seat of your pants might
| be really poor engineering practice, or you might be doing
| cutting edge work that people will be studying decades from
| now. Those rules of thumb might be a result of personal trial
| and error, or you might be getting them from a detailed
| technical manual. It just depends on what the state of the
| art is, the maturity of the field, etc.
| Jtsummers wrote:
| > Any definition of engineering which excludes the Wright
| brothers and James Watt, who _invented the machine that
| gives the field it's name_ is a fairly poor definition. If
| you're creating something in a poorly understood situation
| by applying rules of thumb, you're doing engineering.
|
| You seem to be implying that the Wright brothers built
| planes based on rules of thumb. They built scale models and
| a wind tunnel precisely so they could measure and design
| their plane more effectively.
| empath75 wrote:
| A "rule of thumb" isn't just guessing. My point is that
| they weren't accredited members of an engineering
| organization following established guidelines from
| regulations. They were figuring it out how to build an
| airplane without having any real scientific theory for
| how airplanes could work or any established engineering
| practice for how to build one.
| hosh wrote:
| Software would benefit more from some training in philosophy
| than in scientific thinking.
| jerf wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| https://en.wikipedia.org/wiki/ANSI_C, Software Engineering is
| also codified imho.
| beAbU wrote:
| > 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?
|
| I think this is a very good point!
|
| If you are writing the control software for a rocketship's
| avionics, you probably need to have _some_ understanding of
| aeronautics, control theory, signal processing etc.
| Ultimately the act of writing the software is merely an
| expression of all the math and theory that you have spent a
| lifetime acquiring.
|
| Inversely, the engineer who is speccing out the control
| software for a nuclear reactor is essentially writing the
| software for it. It's just in human readable format such that
| the human journeyman who's actually slinging the code can
| implement it. By the time the code is being written, the
| engineering work has been done already.
|
| Programming is much closer to bricklaying or assembling or
| machining. Software engineering is much closer to
| architecture design, and does not involve a lot of code
| writing.
| mamcx wrote:
| The problem is the deps: You can have Rust with no nulls, but
| the OS was made by it. You can have a RDBMS with ACID, but the
| file system is liar.
|
| Then, you can make a product that was applied engineering, but
| you can't replace all the others that not.
|
| Civil engineering and friends have the advantage that is built
| on top of the universe, that despite claims to the contrary,
| was not hacked with perl!
| Twey wrote:
| Engineers also have this problem: if the transistor doesn't
| meet its claimed tolerances then the robot won't either.
| igsomething wrote:
| Electronic Enginering is also not that old and it has been a
| proper engineering discipline for many years already
| kjkjadksj wrote:
| Didn't the egyptians sort of standardize it?
| GrumpyYoungMan wrote:
| > " _How many centuries did it take for civil engineering, for
| example, to become the codified, standardized, and respected
| calling it is now?_ "
|
| But the software industry is not starting from centuries ago.
| We have the benefit of modern education and literacy rates,
| instantaneous global communication, centuries of experience and
| data in other life and safety critical fields to draw on to
| understand how to establish a reasonable level of safety in the
| face of uncertainty, vast libraries of knowledge and data that
| can be called upon online, and nearly a century of increasing
| regulation and professionalization in those fields. Sorry but
| that doesn't hold up to scrutiny.
| karaterobot wrote:
| 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.
| apalmer wrote:
| 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.
| NitpickLawyer wrote:
| > 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 wrote:
| I think, rather, you're romanticizing what "real" engineering
| looks like.
|
| Real engineering doesn't mean that mistakes are never made or
| that there are never bugs. Rather, it is that systems are
| tested thoroughly enough, and designed with enough failsafes
| and redundancy, that safety concerns are mitigated.
|
| The problem in the Boeing case was not that the software had
| bugs. Lots of aviation software has bugs, it's actually very
| common. Rather, the problem was that they did not design the
| system to be safe in the event a bug occurred.
|
| How that looks exactly tends to differ depending on the
| system. As a common example, many aircraft systems have other
| systems which monitor them and emit a warning if they detect
| something which doesn't make sense. Though this would've
| required Boeing to create technical material for pilots on
| how to respond to this new type of warning, which would've
| required training updates, which would've required
| recertification of their plane design, the cost of which
| Boeing desperately wanted to avoid. Fortunately
| (unfortunately), FAA oversight had become very lax, so Boeing
| instead just downplayed the safety concerns and nobody asked
| any questions.
| marcosdumay wrote:
| > Rather, it is that systems are tested thoroughly enough,
| and designed with enough failsafes and redundancy
|
| Yeah... That's one of the main reasons why engineers from
| most other disciplines have a lot of difficulty creating
| large reliable software.
|
| Testing systems and adding failsafes are not nearly enough
| for system reliability, and not the best way to add it to
| software. It's almost enough for mechanical engineering...
| Almost, because it's not enough to make human interactions
| safe.
| wavemode wrote:
| > Testing systems and adding failsafes are not nearly
| enough for system reliability, and not the best way to
| add it to software.
|
| Then what is the best way?
| isodev wrote:
| > it's a 'software doesn't really kill people so government
| doesn't intervene in it'
|
| I think we've reached the point where this is no longer true -
| self driving cars, supposed robots you can take home, LLMs
| being unleashed to randomly guess at medical data or write
| software to do verification or sensitive tasks.
|
| I think software engineering is definitely engineering, we've
| just been successful in lobbying against proper regulation. But
| all that is changing, the EU is introducing the Cyber
| Resilience Act and I think we need a lot more of that.
| binary132 wrote:
| Pet Food Store App does not really need Real Engineering, no
| rdiddly wrote:
| Any place money is changing hands needs at least enough
| engineering, enough "application of scientific principles,"
| to do it securely. Observably failing at that task means it
| ends up not being a pet food store. (It ceases to exist or
| becomes a scam instead.)
| isodev wrote:
| It really does. The pet food store app asks me for my cat's
| allergies and medical conditions. Someone needs to be
| responsible if they fuck it up. Same with self driving cars
| - the whole idea of "engineering" is about quality and
| responsibility.
| jiriro wrote:
| > the whole idea of "engineering" is about quality and
| responsibility
|
| This is hilarious :-)
|
| Making things that work has precisely zero relationship
| with quality or responsibilty or whatever shit you wish.
|
| Of course you can pay me anytime for quality or
| responsibility or whatever :)
| sarchertech wrote:
| "Quality" is subjective, so you're correct that it's not
| about quality. A tool designed with a planned lifespan of
| 100 hour lifespan is just as much a product of
| engineering as one designed to last 10k.
|
| Responsibility though is very much is a central component
| of capital E Engineering. The modern profession in many
| ways is a direct response to big newsworthy engineering
| disasters.
| array_key_first wrote:
| Software companies are definitely flying too close to the sun
| here. I don't think this is sustainable, at all.
| NaomiLehman wrote:
| software is more like writing books than engineering
| empath75 wrote:
| Government did not invent the discipline of engineering. This
| is just completely backwards. How do you think all of those
| engineering organizations came up with those manuals and
| regulations, were they not doing any engineering until they
| published a manual? Complete nonsense.
|
| https://www.youtube.com/watch?v=_ivqWN4L3zU
| ch4s3 wrote:
| Things software engineers believe about history/government...
| estimator7292 wrote:
| Who makes the software that "real" engineers use to design
| bridges? Can developers of such software afford to be any less
| rigorous than the "real" engineers?
| NoMoreNicksLeft wrote:
| Most software flaws would manifest during the design phase,
| and a crashed application just causes design delays (pushing
| back bridge opening, but still). The sort of software flaw
| that would cause the application to not crash, but to
| mysteriously micalculate some load/shear/whatever limit seems
| unlikely. You'd almost need a silicon bug, a floating point
| unit that just totally shits the bed and comes up with a
| retard result.
|
| That said, I'm in general agreement that the software
| developers should be as rigorous as the "real" engineers, but
| that's often just impossible from an office politics
| standpoint.
| AlotOfReading wrote:
| The sort of software flaw that would cause the application
| to not crash, but to mysteriously micalculate some
| load/shear/whatever limit seems unlikely.
|
| Numeric instability is not only possible, but downright
| common in application software. You don't need exotic
| floating point issues to cause it.
| thenthenthen wrote:
| Therac-25 entered the chat
| GrumpyYoungMan wrote:
| Software "engineering" doesn't kill people instantly in a
| flashy way, sure, but it has become more like leaded gasoline,
| a widespread low-level harm whose effects are increasingly
| evident in hindsight. You pretty much can't go more than a
| couple of days without hearing about another massive consumer
| data compromise by hackers, CVE, major services outage, etc. At
| some point, there is going to be a software related incident
| that is bad enough that the public and government is going to
| demand accountability.
| ge96 wrote:
| Boeing, insulin pumps I could think of, missiles exploding on
| the pylon, lot of ways software can (almost) kill instantly,
| like that rocket that started flying sideways due to I think
| switching measurement units
| HeyLaughingBoy wrote:
| Never heard of the rocket, but the software in at least the
| first two items is already developed to existing
| engineering standards by law.
| ge96 wrote:
| oh it's Arian 5 integer overflow
| dingnuts wrote:
| The Azure and AWS outages affected hospitals.
|
| You know there had to have been increased literal pain and
| suffering from patients while hospitals scrambled to fall
| back on old methods of coordination and communication.
|
| This shit is serious and I'm tired of people arguing that
| our craft should not be taken seriously.
|
| A lot of us work on infrastructure just as vital as bridges
| and tunnels, and with real world consequences when these
| things fail.
|
| Take some responsibility.
| GrumpyYoungMan wrote:
| The things you list illustrate @aplamers point that
| software "doesn't really kill people". If you asked the
| average person on the street, they might just barely
| remember the Boeing incidents and the rest they probably
| have never heard of. Even something as gruesome as the
| Therac-25 incident is probably unknown to most.
|
| It's the rising tide of low-level everyday harm from
| software that is going to motivate the public to start
| coming after the software industry.
| toast0 wrote:
| > This again? In general, Software Engineering is not
| engineering.
|
| Software Engineering is definitely Engineering. But Software
| Development usually doesn't practice it. I've got a degree in
| Computer Engineering and took SE courses and at least at the
| companies I've been at, we never did any of that. You can't use
| formal methods without a formalized specification, and I never
| even got a written specification of any project I worked on in
| 20+ years. Regardless, Software Engineers don't wear stripey
| hats and are not real engineers.
|
| There's not much structual engineering in single family home
| construction either. A couple story wood frame building needs
| to be pretty exotic to have structural issues (but soft story
| buildings used to be common and collapse with strong
| earthquakes)
| tsss wrote:
| You never got a properly dimensioned wireframe model from
| your UI designer? That's a specification too.
| toast0 wrote:
| I don't do a lot of frontend work. But when I did, the
| mocks were almost always best case; no mocks for when there
| was missing data (which was often). I did work on one
| project with an interaction designer, which was great ---
| having all the flows laid out was awesome, but it was only
| the happy path.
| rdiddly wrote:
| Safety is not the only parameter that can be engineered
| (obviously), nor is it the only one subject to regulation.
| Efficiency for example is regulated, like when the EPA states
| what an appliance must accomplish while using some amount of
| energy. Meeting that guideline takes engineering.
| jayd16 wrote:
| It's an interesting discussion.
|
| Developing an application is applying techniques but by nature,
| you don't really build the same application many times such
| that you can come up with rules that the daily grunt applies
| without thought.
|
| What is the software equivalent of spacing studs interspersed
| with fireblocks that we're not doing?
|
| In software, easily repeated steps and proper practices are
| moved to the runtime/language/compiler etc.
|
| Is it too conceited to argue that each application is more
| unique than each housing structure? I'm not sure. But we do
| actually have many many practices in place that are
| automatically handled.
| RHSeeger wrote:
| > What is the software equivalent of spacing studs
| interspersed with fireblocks that we're not doing? > > In
| software, easily repeated steps and proper practices are
| moved to the runtime/language/compiler etc.
|
| At least in my opinion, that doesn't make them _not_ the
| equivalent of spacing studs interspersed with fireblocks,
| etc. It just makes it automatic... the same way that
| contractors buy materials that have certain things build into
| them (weather resistant, fire retardant, etc).
|
| Just like it's entirely possible to build software without
| using common libraries (roll your own, etc); one can do the
| same with buildings. The only difference is the official
| rules requiring they way things are done.
| HeyLaughingBoy wrote:
| > What is the software equivalent of spacing studs
| interspersed with fireblocks that we're not doing?
|
| You're comparing apples to hockey pucks. For the analogy to
| hold, you need to specify what industry the software is for.
| i.e., if I'm building a garden shed, I don't need a specific
| stud spacing or even fireblocks at all. Hell, I can build it
| from raw timber if I have enough of it.
| 64718283661 wrote:
| Many engineered physical devices can't cause harm to their end
| users the same way you say software cannot. And many software
| applications can cause harm to people both directly and
| indirectly. See social media, or hacks and data leaks which can
| destroy the lives of individuals or countries.
| jandrewrogers wrote:
| Almost no physical engineering requires licensing either. Most
| things are YOLO-ed without a licensed engineer because it isn't
| required and adds little value.
|
| The issue is that software systems are _qualitatively_ more
| complex than any physical system due to their intrinsic
| malleability. Physical systems are sufficiently simple that
| formal verification methods are actually tractable (and used).
| isodev wrote:
| Physical products require the CE mark [0], so software
| systems (especially the complex ones) should be able to meet
| the same standard because they're used in places where bugs
| and glitches can cause harm.
|
| [0] https://europa.eu/youreurope/business/product-
| requirements/l...
| ponector wrote:
| CE mark does not say anything about quality.
|
| Same way critical software has all kind of sertificates.
| rcbdev wrote:
| The Cyber Resilience Act, conceived as a product security
| regulation on software, will mandate a CE mark on software
| products.
| bsoles wrote:
| This again? You don't need a license to be an engineer. Every
| graduate of an engineering school at an accredited
| university/college IS an engineer. People seem to conflate an
| "engineer" with a "professional engineer". The two are not the
| same; the latter requires a license. At least in the US.
| sarchertech wrote:
| There are states that regulate the bare term "engineer"
| depending on the context.
|
| And all states require a license to offer certain engineering
| services, so practically speaking in certain fields you can't
| "be an engineer" without a license.
|
| For example in most (all?) states you can't hang up a shingle
| adverting yourself as an "Engineer" doing structural work
| without a license even if you aren't calling yourself a
| "Professional Engineer".
| dec0dedab0de wrote:
| I always liked the RMS take that programming is a craft.
| mitthrowaway2 wrote:
| When a software error can simultaneously shut down hospitals,
| air transport, ground transport, emergency services, and
| telecommunications, I don't see how the design of that software
| system should be held to a different legal standard than the
| design of, say, a steam turbine at a power plant, or the
| electrical grid itself.
|
| https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...
|
| > "The outage disrupted daily life, businesses, and governments
| around the world. Many industries were affected--airlines,
| airports, banks, hotels, hospitals, manufacturing, stock
| markets, broadcasting, gas stations, retail stores, and
| governmental services, such as emergency services and websites.
| The worldwide financial damage has been estimated to be at
| least US$10 billion"
| sarchertech wrote:
| It's because it doesn't directly kill a bunch of people all
| at once in a way that causes public outcry.
|
| If it weren't for the many large scale "flashy" engineering
| disasters that caught the attention of the average person, we
| wouldn't have any of the Engineering regulations we have
| today.
|
| My guess is that at some point some piece of software will
| kill enough people or cause a large enough economic disaster
| that we'll start seriously regulating it.
| efitz wrote:
| 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 wrote:
| > 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
|
| [2] https://en.wikipedia.org/wiki/Silurian_hypothesis
| skeezyjefferson wrote:
| what do you think the cambrian explosion was
| Normal_gaussian wrote:
| 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.
| imglorp wrote:
| This is closely related to why Sussman and Abelson stopped
| teaching SICP: it is not possible to engineer software any more
| because systems are too complicated to completely understand and
| abstractions hide too many behaviors. So now we do "programming
| by poking" to understand what the system does instead of making
| it correct by construction.
|
| http://lambda-the-ultimate.org/node/5335
|
| We just tinker. That's all we can do to get stuff done.
| api wrote:
| There have been serious efforts at software engineering, like
| the OOP movement in the 1980s and 90s to construct software
| very methodically.
|
| Programmers hate it and rejected it.
|
| To be fair, it does tend to create its own pathology. Instead
| of a layer cake made of congealed spaghetti, you tend to get
| _over_ -engineering.
|
| https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
|
| Software engineering leads to software over-engineering because
| unlike in physical material engineering there is no capital or
| material cost to push back against complexity. You can just add
| things, and add things, and add things, forever, and it costs
| very little (a bit of RAM and CPU but that's cheap).
|
| I have this weird hypothesis that part of why methodical
| "correct" software engineering fails is that it succeeds. It is
| able to manage complexity, which allows complexity to grow
| without bound. A mountain of ugly shit will start crashing in
| mysterious ways if it gets too complex, which has the virtue of
| limiting complexity.
|
| A root problem is that programmers tend to add complexity, not
| remove it, and the incentive structure of the software business
| tends to encourage this. 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 wrote:
| Look at ECS and game dev. Some may say games are just
| products, yet some real engineering is done in some places.
| api wrote:
| Good game dev shops tend to have some very good programmers
| in them. Game dev has pioneered ideas like data oriented
| development, which are not suitable for everything but are
| cool.
| porridgeraisin wrote:
| > I have this weird hypothesis that part of why methodical
| "correct" software engineering fails is that it succeeds. It
| is able to manage complexity, which allows complexity to grow
| without bound.
|
| Interesting thought that. Makes a lot of sense. Will remember
| it the next time I randomly have a train of thought about
| software complexity on the bus... Am I normal? does everyone
| here do that? Of course outside hackernews this is a hopeless
| question.
| tptacek wrote:
| Helps to have more of the quote:
|
| _He said that programming today is "More like science. You
| grab this piece of library and you poke at it. You write
| programs that poke it and see what it does. And you say, 'Can I
| tweak it to do the thing I want? '". The "analysis-by-
| synthesis" view of SICP -- where you build a larger system out
| of smaller, simple parts -- became irrelevant._
| HPsquared wrote:
| We've gone from synthesis to distillation.
| Marshferm wrote:
| Which means software is trapped behind the evolutionary lens.
| And without a direct connection between goal and method, it's
| like an out of control path to extinction.
| uvaursi wrote:
| I'll stick my neck out and say SICP has never been relevant to
| me. I've tinkered from embedded, to OS, to databases, to
| desktop applications, drivers, compilers, web applications, and
| all sorts of shit inbetween when I'm not reversing some archaic
| binary compiled in a pre-standard C++. I've done both idiomatic
| programming in a language as well as applying idioms from other
| languages that I liked. I've turned C# into Lisp because it
| couldn't do what I needed it to do. I read through ARM opcode
| docs while I'm daydreaming of writing Ruby.
|
| When I looked at SICP I saw one thing: an introduction to
| "thinking about programming" for people who will have to re-
| learn everything and will maybe use a few things here and
| there. The fundamentals matter but the application is the
| "everyone has a plan until they get punched in the face" phase
| of actual learning. There are much better ways to go about
| studying and learning and I found SICP lacking, among other
| course work that I think is taught backwards and makes it hard
| to reason and apply.
|
| Read "Great Programmers" by Bram Cohen. The wisdom is there,
| but it's lost on people.
|
| Just my 2c.
| pwndByDeath wrote:
| Software is the one discipline we can have perfection. In every
| other engineering there are tolerances, unknowns we have to
| yield to nature. In software we are god. We're just a lazy and
| stupid god.
|
| Anecdotal, I had a coworker working on a new feature in a huge
| code base. I was trying to ignore the pseudocode planning they
| put on the board. After a moment of frustration I wrote down 6
| conditionals that simplified what would become hundreds of new
| lines, to those 6 statement, and capture a few more corner
| cases they had not worked out yet.
|
| Months later I got a green light on a total overhaul of the
| larger code base and we turned a massive code base into a fully
| automated and effectively bullet proof distributed system
| because I took the time to apply engineering principles to.the
| problem. The code wasn't always the most proper (I did things
| downright sinful) but the system was organized like an
| engineering project with interdependent subsystem instead of a
| rube Goldberg kludge of new.function on old. That overhaul too
| less time than any of the prior incremental feature updates
| prior.
| BeFlatXIII wrote:
| Software as science.
| kjkjadksj wrote:
| If that is the case any biological engineering is also
| impossible since no one understands the full system.
| z3t4 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| IlikeKitties wrote:
| >I've always wondered why UFOs are only a USA phenomenon
|
| It plain isn't and to claim that it is shows that you have done
| EXACTLY 0 research into the topic. This kind of bad faith
| engagement shows an utter lack of curiosity.
|
| UFOs are huge in South America within just seconds you can find
| hundreds of sightings and discussions about them:
|
| https://en.wikipedia.org/wiki/Varginha_UFO_incident
|
| https://en.wikipedia.org/wiki/UFO_sightings_in_Brazil
|
| https://www.vice.com/en/article/i-went-alien-hunting-on-chil...
|
| Ufos are also a thing above Europe with the Belgian Ufo wave
| and the Rendlesham Forest incident being well known and seminal
| cases in UFO Lore
|
| https://en.wikipedia.org/wiki/Rendlesham_Forest_incident
|
| https://en.wikipedia.org/wiki/Belgian_UFO_wave
|
| Africa also had for example the ariel school incident in
| Zimbabwe, one of the most well known UFO cases ever
|
| https://en.wikipedia.org/wiki/Ariel_School_UFO_incident
|
| https://en.wikipedia.org/wiki/UFO_sightings_in_Africa
|
| Same goes for russia where after the cold war ufo sightings
| were discussed in offically declassified documents:
|
| https://www.cia.gov/readingroom/docs/DOC_0005517761.pdf
|
| Must I go on or is that enough to accept that "UNKNOWN THING IN
| SKY DOES WEIRD THING I DON'T UNDERSTAND" is pretty much a
| global phenomenon that can and should be scientifically
| investigated just the same as we would investigate everything
| else we find anomalous?
| 1970-01-01 wrote:
| This doesn't prove it's aliens. It does add to my mass-
| hysteria hypothesis. I want to see the biological remains
| firsthand in Zimbabwe, Japan, etc. I want to see the crater
| the UFO left on the ground. I want to see the craft. Where's
| the physical evidence? Not photos, actual dirt displaced,
| metal alloy, extraterrestrial biological remains, etc.
| IlikeKitties wrote:
| > This doesn't prove it's aliens. It does add to my mass-
| hysteria hypothesis
|
| You don't notice it do you? Re-read again what I wrote. At
| no point did I argue that it's aliens. Intentionally.
|
| You first point was proven wrong instantly "it's only an
| USA Phenomenon". You don't bother to research anything but
| stick with your hypothesis. You don't even go look for
| evidence yet are utterly convinced of the result of your
| complete lack of research.
|
| Here's an example of metal alloy that's supposed to come
| from an UFO and shows an interesting composition we cannot
| replicate. It's a well known artefact:
|
| https://tothestars.media/de-de/blogs/press-and-news/tts-
| anal...
|
| It had some analysis done by different researchers https://
| www.researchgate.net/publication/237233241_Compositi...
|
| Your lack of curiosity is still very obvious.
| 1970-01-01 wrote:
| Good job not using the emdash. Your learning so quickly
| esseph wrote:
| I have no dog in this fight, but I want to ask a question.
|
| What are your thoughts about multiple pilots in formation
| seeing things that are corroborated by optical, laser, and
| radar sensors used by the local aircraft and remote radar
| platforms?
|
| Because that's where things get fun! :)
| IlikeKitties wrote:
| Sadly you'll see from his other responses that thinking
| is the thing he doesn't
| jcranmer wrote:
| > I've always wondered why UFOs are only a USA phenomenon.
|
| They're not. There are however two factors greatly biasing your
| perception of UFOs. First, it takes a fair amount of effort to
| track down information in foreign language sources, so in
| general there's going to be a lot less English-language
| information on Chinese, Russian, or Japanese reports of UFOs.
| Second, militaries are going to both generate more UFO reports
| (thanks to military research programs that go awry, e.g., the
| circumstances behind the Roswell incident) and be a lot more
| open to collecting and investigating them (because of their
| ability to indicate the previous point). The US military being
| the largest and most well-funded in the world is thus going to
| generate the largest UFO report halo around it.
| uvaursi wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 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 wrote:
| 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
| skeezyjefferson wrote:
| 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 wrote:
| Most people aren't software engineers, so it's not clear why
| that should be a problem.
| mitthrowaway2 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Sturgeon's Law.
|
| For counter-examples see:
|
| https://www-cs-faculty.stanford.edu/~knuth/taocp.html
|
| and
|
| https://www.youtube.com/watch?v=bmSAYlu0NcY
|
| which is about the wonderful book:
|
| https://www.goodreads.com/book/show/39996759-a-philosophy-of...
| okaleniuk wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I'm going to refer to Philosophy of Computer Science (
| https://news.ycombinator.com/item?id=20912718
| https://news.ycombinator.com/item?id=10388603 ) and say "its not
| an easy or decided problem".
|
| Section 3 has about 100 pages (in the pdf - I'd have to dig
| around to find the hard copy) that tries to look into what
| computer science is. Section 3.10 starts comparing it with
| engineering... and noting that it's looking at _computer science_
| rather than programing aspect of it. Part of the questions being
| asked is "is computer science a science?"
|
| I'm going to highly recommend the book for those interested in
| these questions. I'll also point out that across its thousand(!)
| pages, this book is in large part a survey of the literature of
| tens of thousands of _more_ pages on the subjects.
|
| I don't believe that most people are approaching software
| development (be it called computer science or software
| engineering) with either the mindset of a scientist or an
| engineer (there are times when one of those mindsets is
| necessary) Rather, I agree with a later section in it...
| 3.14.7 Is CS Magic? The great science-fiction author
| Arthur C. Clarke famously said that "Any sufficiently advanced
| technology is indistinguishable from magic"
| (http://en.wikipedia.org/wiki/Clarke's_three_laws). Could it be
| that the advanced technology of CS is not only indistinguishable
| from magic, but really is magic? Not magic as in tricks, but
| magic as in Merlin or Harry Potter? As one CS student put it,
| Computer science is very empowering. It's kind of like knowing
| magic: you learn the right stuff and how to say it, and out comes
| an answer that solves a real problem. That's so cool. --Euakarn
| (Som) Liengtiraphan, quoted in Hauser 2017, p. 16 Brooks
| makes an even stronger claim than Clarke: The programmer,
| like the poet, works only slightly removed from pure thought-
| stuff. He [sic] builds castles in the air, creating by the
| exertion of the imagination . . . . Yet the program construct,
| unlike the poet's words [or the magician's spells?], is real in
| the sense that it moves and works, producing visible outputs
| separate from the construct itself. . . . *The magic of myth and
| legend has come true in our time. One types the correct
| incantation on a keyboard, and a display screen comes to life,
| showing things that never were nor could be.* (Brooks, 1975, pp.
| 7-8, my emphases). ... Clearly,
| programming involves exactly that kind of use of symbols. Or, as
| Abelson & Sussman put it in their introductory CS text (which we
| discussed in SS3.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://news.ycombinator.com/item?id=27029196
| ipsento606 wrote:
| 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 wrote:
| man, if you want engineering guarantees, you're gonna have to pay
| for them, both in currency and realistic requirements.
| alde wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Safety is the concern of "professional engineering".
| "Engineering" is about designing systems -- that may or may not
| be safe.
| jayd16 wrote:
| 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 wrote:
| 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/
| Twey wrote:
| 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 wrote:
| 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.
| culebron21 wrote:
| 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 wrote:
| 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 wrote:
| Just going to leave this here: https://www.amazon.com/Safeware-
| Computers-Nancy-G-Leveson/dp...
|
| Note that this book is _30 years old_!
| keeda wrote:
| 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)
|
| 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 wrote:
| 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/
|
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-07 23:02 UTC)