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.
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.
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 :)
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.
If you pay me I can of course sell you some responsibility or whatever. This is called business.
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.
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.
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)
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).
[0] https://europa.eu/youreurope/business/product-requirements/l...
TFA (and your comment indirectly) seem to be about the lack of rigor in software engineering. However, any discussion of engineering that leaves out economics and costs is fundamentally incomplete.
The only reason most software development seems to have less rigor is because the economics of most software projects permit it. Other domains of software engineering where lives are on the line definitely have high levels of rigor.
I wrote a lot more in this other comment: https://news.ycombinator.com/item?id=45849304
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.
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.
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.
Then what is the best way?
And just to say, the fact that nobody has any idea how to engineer systems reliability is the main reason why we have a duopoly in large airplanes that everybody expects to turn into a monopoly soon. If we knew how to do it, companies would pop into the market all the time.
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.
I would say the exact opposite, actually. Two random software applications designed for the same purpose are likely much more similar to each other than two random buildings that were built for the same purpose.
This is because, for practical reasons, the software applications are likely just going to be slight variations of the same base. Unless your application is extremely intricate, most of the complexity (and most of the code that's executing) is actually in the kernel and the libraries. You're mostly just reusing those shared components and arranging them in a slightly different way.
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.
I'm not sure what your point is. Like, ok, you came up with a structure that doesn't need a lot of structural engineering but clearly others do. So what are you trying to say?
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.
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.
The sort of software flaw that would cause the application to not crash, but to mysteriously micalculate some load/shear/whatever limit seems unlikely.
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"
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.
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”.
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/
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.
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.
Then, you can make a product that was applied engineering, but you can't replace all the others that not.
Civil engineering and friends have the advantage that is built on top of the universe, that despite claims to the contrary, was not hacked with perl!
But 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.
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.
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.
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.
http://lambda-the-ultimate.org/node/5335
We just tinker. That's all we can do to get stuff done.
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.
The reality is that the machines we write software for are complex, and trying to abstract it away and simplify it will introduce more abstractions that someone has to understand and deal with when they inevitably leak. It's not all bad, all this shit we're writing makes a lot of money.
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.
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.
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.
On a thread about software bloat and inefficiency, @josephg once speculated about an alternate universe where Moore's Law stopped decades ago. I've kept thinking about that. Unfortunately, I kept coming up with counterfactuals where important things like accessibility weren't as advanced or (relatively) widespread as they are in this world.
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.
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.
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.
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.
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.
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.
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.
https://www.washington.edu/news/2020/03/02/not-a-math-person...
If you talk about editing the data structure, then it depends.
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.
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.
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.
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.
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.
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.
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.
* 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.
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.)
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.
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.
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.
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)
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.
How much of modern software practices would exist today if the senior engineer needed to sign off on a project?
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.
* 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.
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
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.
Absolutely. But are visitors from other star systems any less unlikely?
Visitors from other star systems are significantly more likely (on the order of dice roll vs impossible) than a secret highly advanced human society developing and remaining present and hidden.
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".
(Not to diminish good craftsmanship, which I highly value.)
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.
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.
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.)
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...
In other areas, software engineering seems a lot like alchemy, ages before it became the serious science of chemistry.
Software is neither engineering nor science, so the terms Software Engineering and Computer Science are mislabels at best and extinction propaganda at worst.
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.
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.
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?
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! :)
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.
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.
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.
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.
“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.
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.
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?
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?
Note that this book is 30 years old!
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.
the idea that all, or even most, "software engineering" is real engineering is laughable
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.