Agile came from toyota?

My understanding is that Kanban came from Toyota, which is an agile way of working.

This is a fascinating article about the history of software development. For me the key quotes are:

The thing that killed Waterfall was that discovering your spec was wrong months later, after lots of code had been written - and fixing it cost a fortune because writing code was the most expensive part of the process.

The key reason Agile was invented was to account for the high cost of writing code, so yes, that part of the Agile value proposition is no more.

The risk isn’t that AI development is inherently Waterfall. The risk is that organizations with latent Waterfall instincts will use spec-generation as license to do the bad thing they always wanted to do — front-load requirements, skip customer validation, equate a fancier document with a better outcome, and ship one massive thing every quarter.

This quote from the article really sums it up:

And to be clear, I don’t care whether you typed the code yourself. I care whether you understood it before you shipped it. I care whether you can explain why the bug happened, why this fix is the right fix, what the model might have missed, and what would make you roll it back.

Could you elaborate on this?

Thank you! I’ve updated the post with the TL;DR from the article.

An acronym for domain-driven design.

Depending on your level of programming experience, you might find the exercises at Exercism quite useful.

In case anyone is curious, this is the original post on X.

I am against scrolljacking too. Though having read through the article, and seen the animation in action at https://whimsy.joshwcomeau.com/, this is not scrolljacking, it’s just something that animates as you scroll. It’s so unobtrusive that I didn’t notice it the first time.

That is a good question. The beauty of the web is that readers can control their experience, be it with ad blockers, increasing the font-size, reader mode, or even changing the whole experience with user style sheets or Greasemonkey. This doesn’t mean it’s a waste of time to bother with pretty designs. People should build websites that they’re proud of, and accept that people might override their design with one better suited to their needs or taste.

Do we know the average user hits the back button when they encounter CSS animations? I was just a conference, and people were talking about browsing the web in reader mode, which I’d argue is more likely.

Given this is achieved with CSS, there is no reason that users can’t disable animations with a user style sheet. In fact this is what some users do, according to a CSS Working Group discussion about disabling view transitions.

Some users do set transition-duration: 0 !important in user style sheets in order to prevent transitions, same with animation: none !important or so.

Could you give more context about what Vercel features you need - is the site statically generated, or do you also need Vercel Functions?

Agreed though the article has this disclaimer:

Before we dive into the code, I think it’s worth pointing out that the goal is largely to be immersive and expose some lore. I think this design and effect fit because of the theme and because it’s not for critical content. My point is that it’s just an aesthetic component for a game that makes this acceptable — I don’t think this is necessarily a good user experience for your every day website where there are stakes.

There are several European based alternatives to Vercel. It’s also worth having a read through or posting to !web_hosting@programming.dev

Though that quote is followed by this, which indicates at least five of those vulnerabilities were real:

I searched the Linux kernel and found a total of five Linux vulnerabilities so far that Nicholas either fixed directly or reported to the Linux kernel maintainers, some as recently as last week:

Your comment reminded me of this article, The Software Quality and Productivity Crisis Executives Won’t Address, which discusses the lack of technical leadership when it comes to tackling technical debt, and that the solution is usually a rewrite.

Instead, most organisations don’t tackle technical debt until it causes an operational meltdown. At that point, they end up allocating 30–40% of their budget to massive emergency transformation programmes—double the recommended preventive investment (Oliver Wyman, 2024).

It’s definitely got the worst defaults compared to the alternatives.

pnpm, Bun, and Deno have all made better choices about their defaults. pnpm blocks postinstall scripts, Bun requires explicit opt-in for them, Deno’s permission model is restrictive by design.

I agree but it depends on how teams create and refine their tickets. For example, you could have high level tickets, and someone picks one up and creates an implementation that’s not an appropriate fit for your architecture.

Thank you for not assuming my motivations. Could you please elaborate on what you mean by “oneshotted”? I share a lot of articles, so I’m not surprised you recognise my username.