We can argue on whether it’s a “bug” outright (since it is technically a correct implementation of a faulty design), but Boeing’s MCAS pitching the plane based on the input of a singular faulty sensor has probably caused billions in direct damages, and billions more in reputational damage.

NULL references (which Crowdstrike is an instance of) are often referred to as “the billion dollar mistake”, but the actual cost of “historical” languages skimping out on optionally-nullable types is certainly in the trillions.

I looked into it after this year’s massive price hike… There’s no meaningful alternative. We’re on the FOSS version of GitLab now (GitLab-CE), but the lack of code ownership / multiple reviewers / etc. is a real pain and poses problems with accountability.

Honestly there are not that many features in Gitlab EE that are truly necessary for a corporate environment, so a GitLab-CE fork may be able to set itself apart by providing those. To me there are two hurdles:

• Legal uncertainties (do we need a clean room implementation to make sure Gitlab Inc doesn’t sue for re-implementing the EE-only features into a Gitlab fork?)
• The enormous complexity of the GitLab codebase will make any fork, to put it mildly, a major PITA to maintain. 2,264 people work for GitLab FFS (with hundreds in dev/ops), it’s indecent.

Honestly I think I’d be happy if forgejo supported gitlab-runner, that seems like a much more reasonable ask given the clean interface between runner and server. Maybe I should experiment with that…

All of this has already been implemented for over a hundred years for other trades. Us software people have generally escaped this conversation, but I think we’ll have to have it at some point. It doesn’t have to be heavy-handed government regulation; a self-governed trades association may well aim to set the bar for licensing requirements and industry standards. This doesn’t make it illegal to write code however you want, but it does set higher quality expectations and slightly lowers the bar for proving negligence on a company’s part.

There should be a ISO-whateverthefuck or DIN-thisorother that every developer would know to point to when the software deployment process looks as bad as CrowdStrike’s. Instead we’re happy to shrug and move on when management doesn’t even understand what a CI is or why it should get prioritized. In other trades the follow-up for management would be a CYA email that clearly outlines the risk and standards noncompliance and sets a line in the sand liability-wise. That doesn’t sound particularly outlandish to me.

But a company that hires carpenters to build a roof will be held liable if that roof collapses on the first snow storm. Plumbers and electricians must be accredited AFAIK, have the final word on what is good enough by their standards, and signing off on shoddy work exposes them to criminal negligence lawsuits.

Some software truly has no stakes (e.g. a free mp3 converter), but even boring office productivity tools can be more critical than my colleagues sometimes seem to think. Sure, we work on boring office productivity tools, but hospitals buy those tools and unreliable software means measurably worse health outcomes for the patients.

Engineers signing off on all software is an extreme end of the spectrum, but there are a whole lot of options between that and the current free-for-all where customers have no way to know if the product they’re buying is following industry standard practices, or if the deployment process is “Dave receives a USB from Paula and connects to the FTP using a 15 year-old version of FileZilla and a post-it note with the credentials”.

Oh I was talking in the context of my specialty, software engineering. The main difference between an engineer and an operator is that one designs processes while the other executes on those processes. Negligence/malice aside the operator is never to blame.

If the dev is “the guy who presses the ‘go live’ button” then he’s an operator. But what is generally being discussed is all the engineering (or lack thereof) around that “go live” button.

As a software engineer I get queasy when it is conceivable that a noncritical component reaches production without the build artifact being thoroughly tested (with CI tests AND real usage in lower environments).
The fact that CrowdWorks even had a button that could push a DOA update on such a highly critical component points to their processes being so out of the industry standards that no software engineer would have signed off on anything… If software engineers actually had the same accountability as Civil Engineers. If a bridge gets built outside the specifications of the Civil Engineer who signed off on the plans, and that bridge crumbles, someone is getting their tits sued off. Yet there is no equivalent accountability in Software Engineering (except perhaps in super safety-critical stuff like automotive/medical/aerospace/defense applications, and even there I think we’d be surprised).

I strongly believe in no-blame mindsets, but “blame” is not the same as “consequences” and lack of consequences is definitely the biggest driver of corporate apathy. Every incident should trigger a review of systemic and process failures, but in my experience corporate leadership either sucks at this, does not care, or will bury suggestions that involve spending man-hours on a complex solution if the problem lies in that “low likelihood, big impact” corner.
Because likely when the problem happens (again) they’ll be able to sweep it under the rug (again) or will have moved on to greener pastures.

What the author of the article suggests is actually a potential fix; if developers (in a broad sense of the word and including POs and such) were accountable (both responsible and empowered) then they would have the power to say No to shortsighted management decisions (and/or deflect the blame in a way that would actually stick to whoever went against an engineer’s recommendation).

Corporate behemoths are going to keep doing what they do best.

Their ISO-whatever certification says they gotta get that kind of software, so they do. Whether it is found to actually increase business risk does not matter in the slightest, what matters is that a box is checked for the audit.

It’s like Oracle or IBM, who did not contribute anything of value to the world since about 2005 and notoriously have some of the most aggressive licensing lawyers on the planet. But there are lots of companies out there who sort a product segment from Old to New and pick the first result on account of the fact that it’s “established”, “reputable” and “reliable”, every other consideration be damned.

There are good sides to DST, such as coming home “earlier” (by the sun clock but not by the social clock) from school or work and therefore having more hours of daylight during the free time after work. These positive effects may go beyond subjective feelings. A study has shown for example that activity increases with longer evening daylight (Goodman et al., 2014) – albeit with small biological effect sizes (≈6% difference in the daily activity between the Standard Time of the year and DST, adjusted for photoperiod). Interestingly these results of the above study were culture-specific: a significant increase was mainly observed in Europe and to some extent in Australia, while no significant effects or even slightly negative effects were seen in the United States and Brazil.

Fucking duh. This is the sticking point for me, and I am disappointed that the article doesn’t mention the effect of latitude here. Very easy for muricans to say “DST is not useful” when these fuckers never get pitch-black night before 6pm or full daylight before 6am ST.

Brussels is on the same latitude as Calgary. ST robs every office worker of one hour of useful daylight. That’s it. That’s the whole argument for permanent DST. Businesses will not change their opening hours, so permanent ST means a net loss of one active hour in the day for every office worker. Permanent DST in Europe means someone working 9-6 would not have to drive home at night for 4 months of the year and could maybe even take the dog for a walk in the evening sun.

I wouldn’t recommend sway to someone who isn’t actively looking for a tiling WM, I would recommend finding a good spotlight equivalent to use on KDE as that will still be less customization work than it would require on barebones sway (which is hardly usable).

It’s not as bad nowadays that apps yielded to GNOME’s bullshit. Back when GTK2 apps were still common… Urgh. Plenty of apps were broken without it for no good reason.

I like opinionated UX - I use sway - but GNOME’s approach is incompatible with “general use” and only works (for now) because of canonical’s weight and ability to impose their vision as the only vision.

Also they didn’t replace the tray with a better way to manage background apps, so they can suck a dick on the UX front.

The fucking system tray. Which literally every other DE and mainstream OS out there supports because some apps depend on it and break if it doesn’t exist.

Last I checked GNOME devs said “no, we will never support it, because we’ve DePRecATeD the tray in GTK”.

It’s functionality so basic I have 3-6 apps which depend on it at any time on my work machine. Anyone saying it doesn’t fall under “basic functionality” is either a GNOME dev or a troll.

What kind of non-agile bottom-up software projects have you experienced? Bottom-up waterfall? I guess it’s possible in theory but that would be a sight to behold.

My only point is that in most situations, upper management are fools that should be left to their devices and should never get a say in development methodologies. By definition if upper management imposes Scrum, it’s a self-defeating prophecy.

Your average tech company should be somewhere in the bottom-right, but bad managers are trying to pull the needle upwards to justify their existence or make up for their incompetence. But they still call that “Agile” (which can be true by some definitions of the word) or “Scrum” (which that isn’t, by definition).

Good software does not come out of companies without a bottom-up approach to software development. Top-down approaches are either terrible or extremely expensive.

Agile development is something that at my company we fought for, not against. It’s literally impossible to fight against actual agile development since it has to come from the workers. Agile is not scrum, and neither are a collection of ceremonies. It’s just a framework to give agency to developers.

Scrum is not the be-all end-all, but in organizations that cannot implement scrum effectively, no system could hope to achieve anything meaningful either.

Scrum aims at empowering workers to remove power from clueless MBAs and meritless CEOs, if they don’t want to play ball then the idiocracy will win every time regardless.

I’ve witnessed similar corporate screwups from the inside, I know the greed and political games and misaligned incentives that allow for such an obviously and catastrophically badly scoped project to be pushed dead-on-arrival in production, against the advice of literally anyone with a pair of eyes and literally any honesty.

Intellectually, I understand. Yet my heart doesn’t, because it refuses to believe the sheer amount of collective stupidity and outright malice at every level of management, consistently for years on end, required to achieve these outcomes. How anyone can sleep at night with “Product Manager for New Outlook” on their resume is beyond me.

I mean, bad programming sucks regardless of the “paradigm” (and vice-versa, mostly). But as someone whose job it often is to sift through production logs hunting for an issue in someone else’s component, at least I have a chance with OOP, because its behavior is normally predictable at compile time. So with the source and the backtrace I can pretty reasonably map the code path, even if the spaghetti is 300 calls deep.

Now where shit really hits the fan is OOP with dependency injection. Now I’m back to square 1 grepping through 15 libraries because my LSP has no idea where the member comes from. Ugh.

Anyone who praises FP is either a student, works primarily in academia, or otherwise never had to look at a deep stack trace in their life.

Every time a production system spits out a backtrace that’s just 15 event loop calls into a random callback, I lose 6 months life expectancy. Then I go look at the source, and the “go to definition” of my LSP never works because WHY WOULD IT, IT’S ALL FUNCTIONAL hapi.register CALLS

I hate it I hate it I hate it I hate it. I support UBI because the people pushing functional programming in real production systems should be reassigned to gardening duties.

Comparing Cloudflare to insurance companies is not how you’ll convince me they’re not acting like jerks lol

So you’ve never once in your life bought a laptop or prebuilt PC, used or otherwise? Because if you have then you’ve paid the Windows Tax.

I’ve read the exact same comment a year ago, and the year before, and probably the year before that tbh.

So I’ll say what I always say; I’ll believe it when I see it.