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.
> 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.
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.)
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.
“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.
When you hire a Professional Engineer there are minimum safety standards that they must meet. They can't charge you less and waive their liability. They are essentially required by law to "sell you some responsibility".
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.
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
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.
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.
> 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)
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.
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).
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.
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.
Software engineering absolutely is engineering. Engineering is not defined by presence of regulations. Engineering is about solving practical problems within the constraints of physical reality and economics.
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.
> 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.
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.
> 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.
Just like with systems reliability, nobody knows it well. But some things we do know are that keeping it simple quickly becomes more impactful than adding failsafes, and you need to design quality holistically from the top down, and not focus at failures or known failure modes.
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.
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.
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.
> Is it too conceited to argue that each application is more unique than each housing structure?
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.
> 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.
That doesn't really sound like an invalid analogy, you just don't need the same fire code for all structures but there are still fire codes that apply to building sheds.
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?
> 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.
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?
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.
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.
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.
> "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"
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.
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.
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”.
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.
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.
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?
> 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.
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.
> "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.
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.
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.
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.
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.
> 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.
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.
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.
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.
Shouldn't that make us want to fight to simplify our software stacks to the point where we can do analysis by synthesis, building from simple, well-understood parts, again?
You can certainly do that if you restrict software to be a mathematical artifact instead of an executable running on one of 3 kernels with different APIs and behaviors, let alone the mountain of dependencies your code will build and link against.
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.
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.
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.
> 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.
> there is no capital or material cost to push back against complexity
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.)
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.
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.
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)
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.
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”.
> 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.
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.
Engineering means lots of documentation. Catalogs of parts. "Red rubber balls", listing all the variations and properties. Standard forms of documentation. Need to describe a file format? Here is a prescribed way to do that. So yes, software is not engineering yet.
I think the reason is that component interoperability problem remains unsolved. The aim of OOP was that; at least Brad Cox saw it this way. One of entries in his blog said something like "software product related to security should not provide security; it should provide tools to build a secure system".
> 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.
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.
Sorry, I was overly polite. It should have read "this is a bloody stupid position to take".
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.
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.
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.
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.
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.)
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!
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.
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.
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.
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!
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?
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.
> 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.
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.
>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:
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?
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.
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?
> 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:
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.
> 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.
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.
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?
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.
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.
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.
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.
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?
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?
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.
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.
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.
> 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.
Software companies are definitely flying too close to the sun here. I don't think this is sustainable, at all.
Pet Food Store App does not really need Real Engineering, no
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.)
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.
> 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 :)
“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.
Responsibility does not have anything to do with engineering capital E or whatever.
If you pay me I can of course sell you some responsibility or whatever. This is called business.
When you hire a Professional Engineer there are minimum safety standards that they must meet. They can't charge you less and waive their liability. They are essentially required by law to "sell you some responsibility".
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.
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
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.
Never heard of the rocket, but the software in at least the first two items is already developed to existing engineering standards by law.
oh it's Arian 5 integer overflow
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.
> 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)
You never got a properly dimensioned wireframe model from your UI designer? That's a specification too.
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.
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).
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...
The Cyber Resilience Act, conceived as a product security regulation on software, will mandate a CE mark on software products.
CE mark does not say anything about quality.
Same way critical software has all kind of sertificates.
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.
Software engineering absolutely is engineering. Engineering is not defined by presence of regulations. Engineering is about solving practical problems within the constraints of physical reality and economics.
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
> 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.
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.
> 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.
> 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?
Just like with systems reliability, nobody knows it well. But some things we do know are that keeping it simple quickly becomes more impactful than adding failsafes, and you need to design quality holistically from the top down, and not focus at failures or known failure modes.
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.
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.
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.
> Is it too conceited to argue that each application is more unique than each housing structure?
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.
> 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.
That doesn't really sound like an invalid analogy, you just don't need the same fire code for all structures but there are still fire codes that apply to building sheds.
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?
> 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.
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?
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.
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"
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.
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.
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”.
I always liked the RMS take that programming is a craft.
software is more like writing books than engineering
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
Things software engineers believe about history/government...
Therac-25 entered the chat
[dead]
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/
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?
> 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.
https://en.wikipedia.org/wiki/ANSI_C, Software Engineering is also codified imho.
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.
> "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.
Electronic Enginering is also not that old and it has been a proper engineering discipline for many years already
Didn’t the egyptians sort of standardize it?
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!
Engineers also have this problem: if the transistor doesn't meet its claimed tolerances then the robot won't either.
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.
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.
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.
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.
> 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.
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.
Software would benefit more from some training in philosophy than in scientific thinking.
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.
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.
Shouldn't that make us want to fight to simplify our software stacks to the point where we can do analysis by synthesis, building from simple, well-understood parts, again?
You can certainly do that if you restrict software to be a mathematical artifact instead of an executable running on one of 3 kernels with different APIs and behaviors, let alone the mountain of dependencies your code will build and link against.
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.
We've gone from synthesis to distillation.
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.
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.
> 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.
> there is no capital or material cost to push back against complexity
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.
Look at ECS and game dev. Some may say games are just products, yet some real engineering is done in some places.
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.
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.
If that is the case any biological engineering is also impossible since no one understands the full system.
Software as science.
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.
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.
> 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.
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.
> 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.
There is definitely some engineering that goes on in the software world, but it's mostly construction.
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.
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.
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.
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.
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.
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).
This one perhaps?
https://www.washington.edu/news/2020/03/02/not-a-math-person...
It would be nice to have a reference.
You mean communication, the transfer of ideas. Already hard between humans, machine language and operation is completely foreign.
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.
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.
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.
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.
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.
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.
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.
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.
Most of software is just plumbing.
And plumbing is a highly skilled and essential profession. And a lot of plumbing work involves engineering to a greater or lesser extent.
That's because AI cannot do physical things yet very well.
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.
[dead]
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.
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.
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.
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.
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.
Safety is the concern of "professional engineering". "Engineering" is about designing systems — that may or may not be safe.
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.
"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.
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.
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.
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.
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/
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.
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.
> 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.
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...
https://jpmens.net/2021/04/09/the-unix-magic-poster/ https://news.ycombinator.com/item?id=27029196It'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.
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.
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?
> 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.
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.
Engineering means lots of documentation. Catalogs of parts. "Red rubber balls", listing all the variations and properties. Standard forms of documentation. Need to describe a file format? Here is a prescribed way to do that. So yes, software is not engineering yet.
I think the reason is that component interoperability problem remains unsolved. The aim of OOP was that; at least Brad Cox saw it this way. One of entries in his blog said something like "software product related to security should not provide security; it should provide tools to build a secure system".
> 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
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.
> This is highly unlikely
Absolutely. But are visitors from other star systems any less unlikely?
Sorry, I was overly polite. It should have read "this is a bloody stupid position to take".
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.
what do you think the cambrian explosion was
It's craft. But what about the math, you say. All kinds of craft demand understanding of the related math.
DEULSION. For example sewing and archery doesn't need math as must have. Same with arabic calligraphy or painting.
The math serves the outcomes, not the other way around.
That’s true for all natural sciences. That doesn’t make them mere craftsmanship.
(Not to diminish good craftsmanship, which I highly value.)
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.
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.
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.
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.)
A more measured and principled take: https://www.hillelwayne.com/talks/crossover-project/
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...
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!
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.
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.
Many governments do not recognize software development as an engineering discipline, and do not treat it (i.e. licensing, regulation) as such.
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
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!
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?
Most people aren’t software engineers, so it’s not clear why that should be a problem.
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.
> 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.
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.
>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?
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.
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! :)
Sadly you'll see from his other responses that thinking is the thing he doesn't
> 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.
Good job not using the emdash. Your learning so quickly
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.
> 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.
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.
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?
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.
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.
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.
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.
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?
man, if you want engineering guarantees, you're gonna have to pay for them, both in currency and realistic requirements.
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?
Just going to leave this here: https://www.amazon.com/Safeware-Computers-Nancy-G-Leveson/dp...
Note that this book is 30 years old!
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.
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
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.