Interesting Links for 13-02-2026

[andrewducker]

1. The Agile Manifesto is 25 years old!

(tags:software development history )

2. Trump failed to indict six members of Congress. This is why it matters (and why juries are important)

(tags:usa law )

3. Putin's megaphone: Orbán's far-right push into UK universities is fuelled by Russian oil

(tags:Hungary Russia bigotry uk )

4. Scottish government bans wet wipes containing plastic

(tags:scotland plastic pollution babies )

Comments

[channelpenguin]

It's one of my casual conversation bombshells with my colleagues that my professional software development career is older than Agile.

Another is that it's also older than the Gang of Four Patterns book....

[andrewducker]

I remember some people being very excited about patterns!

I never got around to reading the book, and it's now been around a decade since I heard anyone mention it, so I reckon I can probably skip it.

[juan_gandhi]

It's sad that the Agile Manifesto (as well as Communist Manifesto), just failed, in essence. The words were used, the ideas were killed.

[channelpenguin]

Patterns were kinda obscure, then got REALLY popular for a while. I suppose that is in itself quite a while ago

[andrewducker]

We had a couple of people in an old job who couldn't have a conversation about software architecture/design without everything having to be named according to which pattern it was, which I found rather off-putting.

[channelpenguin]

I was pretty stunned when I realised that (some of) the youngsters had turned it into a high-ceremony stress factory enabler...

[channelpenguin]

Yeah, I hate that. Me and Sean (5 years older than me and military /space C++ guy) back in the day read it and we're like "that's got a NAME?". It was pretty much all stuff we just DID. Mostly us oldies just think of what I guess might be patterns as "that thing you do when you need to YYY"

[calimac]

Juries, grand juries: not the same things. Both made up of empaneled citizens, though.

[bens_dad]

Formally, mine stopped before Agile (I moved into sys admin).

Looking at the manifesto for the first time, the Manifesto sounds great.
The Principles sound plausible, but many would be deadly if enforced.

In particular Business people and developers must work together daily throughout the project would be great if it happens spontaneously,
but if it is timetabled it must be one of the quickest ways to burn out developers. "daily" is a danger word; "once a day" is bad, "for a good part of every day" could be very good.

[channelpenguin]

Actually did this a few times at investment banks. Was pretty standard back then. Traders, mainly. Horrible people. Many are abusive in every way. Quants were ok. I don't take shit and didn't have to do as much of it as some. It can be very productive.

[channelpenguin]

I mean "working with for a large part of the day", sorry I didn't make that clear.

[botrytis]

1. 25 years of "so, when you say we're doing this in an agile fashion, what do you mean by that?" and "ok, so we're labelling short periods of development as sprints?" et cetera.

[jducoeur]

In particular Business people and developers must work together daily throughout the project would be great if it happens spontaneously, but if it is timetabled it must be one of the quickest ways to burn out developers. "daily" is a danger word; "once a day" is bad, "for a good part of every day" could be very good.

Yep. It also depends on the definition of "business people".

In practice. successful projects have Product Managers who act as the liaisons here -- basically trained and organized in-the-trenches representatives of the "business people". And in practice, yes, I work with my Product Managers pretty much every day, and have done so since the early days. (Indeed, in the formative days of Agile, I would teach novice Product Managers how to interact with the developers productively.)

It works extremely well so long as you have Product Managers who understand their lane, remain available to the developers very freely (for dives into the desired details) and don't try to micro-manage. That's usually the case IME, but the exceptions can get unfortunate.

In general, the ur-principle of Agile is "Do What Works; Don't Do What Doesn't Work". That was clearest in the early days of Extreme Programming (before "agile" was even a thing), and it's deeply sad that that has been steadily eroded over the years. It works when you're very empirical about how well the process is going, and constantly tweak things to make them better.

[jducoeur]

I mean, that's an exaggeration. There are still excellent Agile projects -- I pretty much refuse to work for a company unless it's doing Agile well, and have been doing so for most of the past 25 years.

Unfortunately, enterprises are almost uniformly terrible at Agile: they practice "bullshit Agile", paying lip service while intentionally missing the point. That's why I mainly work for smalll companies.

[jducoeur]

One of the things I've observed is that the really useful patterns have wound up somewhat baked into the language stacks.

For example, over in my Scala-centric world, things tend to be all about Type Classes, and that's great -- but if you scratch the surface, you can realize that Type Classes are kind of a version of the Adapter Pattern with deep language support.

[juan_gandhi]

Of course, with enough internal freedom, companies can practice it well. But where's that freedom. My first conflict at Google was when "agile" was being introduced, and I did the due diligence and read the book, and then I found that nothing like that is being practiced, and I started discussing all this (frankly, I called it a "standup comedy" in an email to the guy who was introducing it to our team), and it turned out that I don't respect the hierarchy, and that's how it all went down since then. I guess they made a black mark on my file.

[jducoeur]

Sure, but that's my point: enterprises are bad at this, and Google has been an enterprise in every respect for a long time now.

Agile works if and only if teams have the agency to figure out exactly what works for them, and management pays attention to reality instead of wishful thinking. Big companies *hate* that. You get promoted in big companies by selling wishful thinking and blaming the other guy when it doesn't work out.

At real startups (and I don't mean "startups" that have raised a billion dollars and have ten thousand employees), Agile doesn't just work, it's existentially necessary. If you aren't flexible and realistic (which are the heart of real Agile), the company dies, nice and efficiently -- it's a downright Darwinian environment.

Hence, my past eight jobs have all been Agile-based, and all have done it at least decently well. It's just plain required.

[juan_gandhi]

Right. I had that experience. If a team is trusted, has a freedom, and doesn't have to appease the management, but, instead produce the working code, there's no reason to have a standup comedy. People work, and talk business.

[channelpenguin]

Yeah, Ruby was (is?) like that as far as I recall. Definitely the Active Record take on data (which I only know from comparison articles on ORMs, I only ever used ruby once in a Hackathon).