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".
> 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.
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 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.
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.
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.
> 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.
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.
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?
That asking about a "software equivalent" isn't possible to answer without specifying an industry or what's being built. It will vary considerably between an human-implantable device or a game on your phone.
> 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.
I don't think the title and the article really communicates it's case well. Did not understand the goal until 90% through the article when they showed the source code of RCL with the loops.
This isn't syntax vs abstraction. This is how much programming language power do you want to enable in your configuration language. This is a big difference and I think we miss the interesting part of that discussion because we dip into this 'abstraction angle.
I think if people want a more powerful, programmable config language, maybe they should use something like Lua or Scheme instead of reinventing the wheel with those new niche languages.
I upvoted this, because while it was critical it didn't feel meanspirited and it was factually correct.
After fully reading the article I came to understand it really was not referring to anything sqllite specific, was really 'what if you ran postgres as an application on a server', there really is nothing more to be gained from reading the article beyond this, and this is kind of the most basic deployment model for postgres for like the last 40 years.
Sure, you are correct! But I've already learned about pglite and sqlite-vector from the comments here alone. So if one reads the article AND the comments, I hope it's a net-positive for you, too, even if the article alone didn't give you anything.
And if not, I hope you didn't spend too long reading. :-)
Ultimately the important thing is that the development team align on the style of programming that they will use at least per project. And the larger the codebase and more developers working on it the more important the consistency in implementing the style guide is.
Imperative programming style has many advantages over functional for some problems. Functional programming style has many advantages over imperative for some problems.
The only clearly 'wrong' approach is codebases where you can look at the code and determine a specific developer on the team wrote feature x because it fundamentally looks completely different from the other sections.
I don't think 'gentrification' is the right word for this. However the comments here do illustrate an underlying 'real' phenomenon what ever you call it.
Just for clarity:
- Non-Japan Asia is new to gaming, and that's okay, it's going to take some time before they find their own voice.
This is not factually true, video games have one of the most popular forms of entertainment in non Japan Asia for 25 years. Nearly a quarter of humanity lives in non-japan asia. There were good non japanese games, bad non japanese games, and more than anything tons of 'mid' non japanese games. They aren't new too it, and they do have their own voices and styles.
What gets talked about as history of video gaming tends to reflect American video gaming history and the unavoidable influence of America's number one vassal state, Japan. Really this is the history of games marketed in North America and that's fine, it just isn't the whole history.
I am not knocking the article but seems like if you are going to dedicate the effort of learning quick mental math it's probably more efficient to 'just' know how to multiple 2 digits quickly than specifically focusing on 2 digit squares...
The ABC approach written about her seems good to me, but I still think of this as abstraction. I get that this is a 'zero' or 'low cost' abstraction but it's still an abstraction. Don't want to be overly nit picky so going to leave it there.
They pretty much lost everyone’s confidence if they fire the CEO and then beg him to come back the next day. Did they not foresee any backlash? These people are gonna predict the future and save us from an evil AGI? Lol
Good for you? Different people have different challenges, I salute you for standing up to yours. I don't think you should change your mind on this, the feeling of sticking to you 'will' is better than any game.
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.