Cost about £500,000 in today’s money. If the AI bubble hasn’t popped by this time next year, that Raspberry Pi might cost about the same.

Agreed.

I’m also a fan of Kent Beck’s “make the change easy, then make the easy change”.

i.e. Do one PR that changes the code’s design but not its behavior, in order to make the next feature easier to implement. Then do another PR that changes just the behavior but not the design.

This way, you get earlier feedback on refactors and you keep behavior PRs small so you reduce the likelihood of the scenario where “we really need to ship this feature but it’s tied to this massive refactor that isn’t quite right”.

(Note that this is just for the case where a feature genuinely requires a refactor. If it’s just “boy-scouting”, then order shouldn’t matter but you should still keep them separate.)

I’ve seen that before. It’s a self-destructive policy.

I’m disappointed by Linux on almost a daily basis. And MacOS. And iOS. And Android.

(I haven’t used Windows in a long time, so I guess it’s the only major OS I’m not routinely disappointed by? Whoa, that’s a realization…)

But this is just what happens when you’re constantly messing with stuff.

Since “do one thing principle” is pretty abstract, I’ll give you one example of a downstream consequence.

I wanted to set up a NixOS microVM using docker sbx. Turns out, it was basically impossible (nothing is actually impossible, it just depends how much you want to modify/rebuild things).

Much of NixOS depends on systemd to manage lifecycles of this or that, but systemd only works properly if it’s the first PID, and when it runs in that mode it also wants to initialize hardware.

But the hardware is all managed by the microVM, so systemd blows up. All it needs to do is nothing, but that turns out to be very difficult to achieve.

If these were like 3 or 4 distinct utilities, there would be obvious seams where I could separate them and only activate the stuff that’s relevant to my use case. But it’s all one big ball of mud.

Customer

I’ve been thinking, the next big personal electronics shift on the level of smartphones will probably be some kind of drone. I don’t think an umbrella will do the trick, but there’s definitely something to this general idea — something that automatically follows you and acts as an extra appendage.

It’s the combination of “breaking changes on minor releases” and “disregard for … production environments”.

Can you stop releasing breaking changes on minor releases? It’s absolutely infuriating that you guys keep doing this over and over again with complete disregard for people downstream using this package in production environments.

By the time you’re deploying to production, you should already have your versions locked in, so semver does not factor into resolving dependencies for production deployments at all.

I can understand it being annoying for development processes. Like, if you have a dependabot-style tool that tests against new releases and submits PRs for them, that can definitely be a waste of time and attention if it fails frequently on patch-level updates.

But in between that “eager testing” step and a production rollout, there needs to be a moment where a human reviews the updates and signs off on updating the lockfile.

And at that moment, reading the changelog, it really doesn’t matter if it says “1.0.1: breaking changes!” or “2.0.0: breaking changes!”, because you need to be looking at the substance of the update.

The only way semver violations burn you in a prod env is if you’re YOLOing new versions out there, either by forgoing a lockfile or by merging lockfile updates without review.

Complains about improper release management.

Apparently not using lockfiles for prod.

This is not a serious developer.

Full context of the first quote:

Those who believe we’ve been in an incrementally escalating software crisis since at least 2007.

Our current software crisis – we’ve had a few – has been ramping up since the US gave up on regulation after the 2007 crash. Instead of reforming and regulating finance, the US decided to let the finance industry take over all of its industries, which hasn’t been great overall, but for software it’s meant that “quality” stopped mattering.

• Well-funded startups capture market share with subsidised products.
• Big tech is a cluster of oligopolies and monopolies.
• Internal software projects are driven by their potential effects on stock prices (“UGC! No, Web 2.0! No, blockchain! No, AI!”).
• Customer lock-in is a standard tactic.

There is little to no downside to poor software quality. The upside of doing the job well is limited compared to tactics like lock-in, dishonest subscription models, and monopolies

If his principal complaint is industry consolidation and consumer abuse, then the browser situation is not a great counterexample.

Credulous slop purveyor

Plot twist: it’s accurate, because the price is not a number but in fact your very soul.

The folks who said barcodes were the mark of the beast were so close!

Very wise words, that will probably go unheeded.

It echoes the theory of constraints mantra of reducing WIP, because WIP itself has a cost.

It’s the modern digital equivalent of the Inclosure Acts

docker-sbx

Get em, Cory!

And here’s the uncomfortable realization underneath all of it: we were relying on a friction we didn’t even know we needed. The playbook for building and sustaining open-source communities—accumulated over decades by a lot of people who took the question seriously—assumed newcomers would keep becoming visible on their own. Nobody wrote that assumption down, because nobody had to. Now that it’s failing, the playbook has to change.

This seems to be a common refrain across all of AI-impacted society: we didn’t know we were losing something vital by reducing friction.

Zoe Bee had a video on basically this topic, back in 2023: https://youtu.be/7-_rK0KkB6k

I’d be curious to see some practical examples.

I’ve seen condition systems before, as an alternative to conventional “from the outside” exception-catching, and thought that was a pretty neat way to preserve the dynamic extent of the throw.

I mean, yeah.

Currently, the predominant business model for commercial search engines is advertising. The goals of the advertising business model do not always correspond to providing quality search to users. … For this type of reason and historical experience with other media [Bagdikian 83], we expect that advertising funded search engines will be inherently biased towards the advertisers and away from the needs of the consumers.

The Anatomy of a Large-Scale Hypertextual Web Search Engine

Sergey Brin and Lawrence Page, 1998

relese