Björkus "No time_t to Die" DorkusOh cool, another Chrome 0-day abusing integer overflow.
Neat.
Great.
Awesome.
Meanwhile, we'll be writing about how we need to have "high impact libraries that help lots of users" and then give examples like CLI Parsing/JSON Parsing before we sit down and go "we should have some standard library types / functions for integers...?".
v.v.v.v. cool prioritization we do here.
We keep calling ourselves software engineers, but engineers elsewhere advance their industry by analyzing failures and building up tools to stop those and make them standard industry practice!
But we'll just have the same 6 problems, on a regular spin cycle, for like 40 years.
Chris@thephd The analyzing and tool building started very early and never stopped, but making them praxis has been weirdly modal. In your analogy, it's like we build cottages and sheds out of reinforced concrete and high-grade steel, but insist on building our longest bridges and tallest sky scrapers out of clay and wood.
Gina Peter Banyard@thephd The thing that is also different in other industries is that the *engineers* are held liable for them signing off, be that in writing or even verbally, on designs.
Meanwhile, in software, we just don't give a flying fuck about it because the consequence of our decisions are going to be felt not by us but by some other random person.
And we even encourage this behaviour, by promoting people that "just ship" shit instead of people that reliably test and think about their choices.
Matt Palmer@Girgias I put a lot of blame on the ability of software makers to disclaim all liability. I can't think of another product category that is able to say "no matter how egregiously bad our product is, any damage it causes is totally not our fault".
Kaitlyn@Girgias @thephd Fun fact, the term "software engineer" is protected in Canada, and genuine Canadian software engineers are held to the same level of liability as other engineers. Big tech companies have gotten in trouble with regulatory bodies over this & change their job titles for Canadian postings
Craig Francis@Girgias @thephd Yep, we just keep looking at the same issues over and over again, and don’t really do anything about them… e.g. most programmers should use memory safe languages, and Injection vulnerabilities should be a thing of the past https://eiv.dev
David Nash@thephd I’ve said before that I’m undecided on whether or not “engineer” is an appropriate title for people working in routine software development and design, but also that people who do want to use the title absolutely should take the time to learn about engineering failures in multiple disciplines. Software failures like the classic Therac-25 fuckup are bare minimum table stakes; it’s a good idea to find something else (ideally, several different types of something else) and learn more about how people addressed those failures, learned from them, and made sure they (and other related cases) didn’t keep happening.
@thephd Here's a concrete (no pun intended) example of a very basic fuckup that should have been caught, wasn't, and killed a bunch of people: the Hyatt hotel suspended walkway that collapsed during an event with hundreds of people, killing over 100 and injuring over 200 more.
The cause? A sudden design change that was inadequately discussed and reviewed, which caused the walkway to support twice the load of the original design, which *itself* was not fully up to proper design specs. The engineer who signed off on the original plans later said "any first-year engineering student could figure it [the error] out." https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse
@thephd One of the outcomes of *this* fuckup: normalization of the idea that (from the article above) "structural engineers are now ultimately responsible for reviewing shop drawings by fabricators." This was the position adopted by the American Society of Civil Engineers as a direct result.
LisPi
Eric Jennings@thephd @baldur yeah. I’m very jealous of my friends who went into actual engineering. I mean there’s plenty to gripe about everywhere and the MBAs screw us all, but when I see the way we’re constantly shooting ourselves in the software world I really wish I had done something where people build something durable and real.
jsj
Not a Spring OnionOh, they definitely do. At one department I knew, there was a research project for aligning data in memory to "look tidier".
No, nobody could explain what that would be good for. 
(This was not about memory alignment or paging or effective use of space.
It was literally a GUI program that allowed users to align little memory rectangles on a 2D canvas.)
Nuclear Oatmeal 
@thephd Oh, but we'll create a new framework or API or maybe... update a standard?
That'll solve the problem.
Florian Schroiff 
@thephd a “website” can be a supermarket brochure or a bank or a diary or medical services. And we treat all of those with the same engineering rigor.
Martin Ruskov@thephd what stops you software engineers from reflective practice and finding ways around these problems? Bertrand Meyer did it
Christian Wolf@thephd ever tried issuing a patch for a bridge? Most software today can be “fixed” in a jiffy. That lowers the quality bar tremendously, and thus, also the costs.
Geert Uytterhoeven@chaos0815 @thephd Bridges are being patched all the time.
Unless they're not.
https://en.wikipedia.org/wiki/Ponte_Morandi?patch
Unless they're not.
https://en.wikipedia.org/wiki/Ponte_Morandi?patch
DCoder 🇱🇹❤🇺🇦@thephd
Tom Simpson’s “Masterpiece Engineering” is 55 years old and it is still painfully accurate.
Tom Simpson’s “Masterpiece Engineering” is 55 years old and it is still painfully accurate.
CyberFoxar@thephd tbh, most of software crafting is more akin to artisanal craftmanship: highly technical, very personal, with a less-than-ideal result.
The title of "Engineer" does not fit 90% of what I do, but "Software Artisan" does not ring a bell to anyone.
The Engineering part of Software Engineer happens very early in development, near the planning phase. It's when technology choices are made, architecture is chosen, and such. Not when the actual coding happens.
Software engineers are expected to code too, which is unusual when compared to other industries: You do not ask a production engineer to actually build and assemble a production line, not do you ask a logistics engineer to do delivery runs themselves.
Yet, software engineers do the planning, the ideation, the problem solving and the implementation. In that way, it's more of an artsan/craftmanship job than other engineering jobs.
Oborosaur@thephd I always found this (and follow-up) post an interesting treatment of this question.
https://www.hillelwayne.com/post/are-we-really-engineers/
I was somewhat surprised that one of the conclusions appears to be "it's just as bad in ((other engineering discipline))" by some oft-cited measures.
Are We Really Engineers?
This is part one of the Crossover Project. Part two is here and part three is here. A conference talk based on this work is now available here. I sat in front of Mat, idly chatting about tech and cuisine. Before now, I had known him mostly for his cooking pictures on Twitter, the kind that made me envious of suburbanites and their 75,000 BTU woks. But now he was the test subject for my new project, to see if it was going to be fruitful or a waste of time.
moved to @
Astatide@thephd I can never decide if the problem lies more on the engineering or the management side (or whether that's a more modern problem in the more dystopian corporate hell we have today).
I do know a number of people who absolutely hate this, but at least for people in the industry, there's no ability (without unions) to refuse ridiculous requests from management such as throwing away whole ass useful closed source tools just because the C suite saw a new shiny.
prozacchiwawa@thephd by fits and starts i think we're getting there. things like CI and coverage based testing are very normal now.
my vision of the future is one where "you're able to write what you can prove" and i think we'll get there too in time as tools for automatic proof assistance get better and the ux of languages with proof systems get better.
Chip Collier@thephd it’s enormously frustrating to me on a daily basis. The tension between doing something correctly with patience and doing something in the artificial timeframes established by “business” interests is exhausting.
I feel like I’m being driven off a cliff by capital interests. And not by like any single human, I mean it’s a weird cultural feedback loop at work.
I feel like I’m being driven off a cliff by capital interests. And not by like any single human, I mean it’s a weird cultural feedback loop at work.
@thephd The funny thing is that I can think of at least two languages standardized since at least 30 years that have long solved this sort of problem (or at least, any implementation of the standards that has these issues is non-compliant/broken as far as the standard specification is concerned).
So this isn't so much "we don't fix the problems", it's "we refuse to even use the fixes because lolidunno".
So this isn't so much "we don't fix the problems", it's "we refuse to even use the fixes because lolidunno".
mgattozzi@thephd "No way to prevent this." says industry where this regularly happens
Luis Villa@mgattozzi @thephd need a 😬 action in Fediverse
Richard Hendricks@thephd I say the same thing every time I have to clear space in my brain for line endings.
Scott@thephd @irenes As the story goes, it was Margaret Hamilton who originated the term, and it’s made much more sense to me since I learned that. The way NASA approaches programming does in fact resemble traditional engineering. Not her fault the rest of the industry glommed onto the term for a little reflected glory.
Mark Levison@thephd my favorite Null.
Robert Kist 🇦🇹🇸🇬@thephd I remember a time where programmers were just called programmers, and then suddenly, everyone became an "engineer"
Robin Syl 🌸
@thephd but I WANT to be an engineer. I just wish my workplace would support that mindset
Nafeon (Backup Account)@thephd that's why I support moving core libraries to rust, zig and julia. They are languages which actually try to fix core issues.
I would actually be fine if we make a breaking change in C# and Java and make them nullsafe for example. Yes you wouldn't be able to compile an old program with it, but it seems so extremely neccessary.
"tep" ✅@thephd You mean, like the first description of a buffer overflow was in the "Anderson Report" around 1965? And that lead to things like hardware bounds checking (Multics), languages with bounded strings and arrays (PL/1, Pascal, Modula), and run-time range checking? And the C came along and...