The contrary is indeed claimed too often. This is far from a simple protocol, and that's probably to be expected seeing its history and success.

Or why the microservice cargo cult which has been going on for a while now infuriates me. It totally ignores the complexity it brings.

Interesting article about expert generalists (also called "paint drip people" by Kent Beck). This is definitely a skill to foster in teams. The article is long enough that I'm not in agreement with everything in it. That being said there's a lot of food for thought here.

Interesting comparison of different definitions for software complexity (which is an ambiguous term to say the least). It leads to nice consequences when team dynamics are considered.

Nice simple fix in Git but with a large impact on backups. A good proof that profiling and keeping an eye on algorithmic complexity can go a long way in improving software.

A good reminder that the complexity of tests should be as low as possible.

Nice illustration on how you can hunt down complexity in your codebases. It is obviously a slow process but comes with nice benefits.

An honest attempt at "vibe coding"... but once again the conclusion is "when it grows to non-trivial size, I'm glad my experience allowed me to finish the thing myself".

Interesting new proof on the relationships between P and PSPACE. Let's see where this leads.

Or why it's hard to truly evaluate performance in complex systems. We often test things in the optimistic case.

A bit of an unusual view about cohesion. The approach is interesting though.

At some point the complexity is high enough that you indeed need more tools than only handcrafted tests to discover bugs.

Nice little article. It's a good way to point out that aiming for the lowest Big-O approach is often not what you want in terms of performance. Always keep the context in mind, and in doubt measure.

Personal backups don't have to be fancy... And probably shouldn't.

A good reminder of why you often don't want to follow an architecture pattern to the letter. They should be considered like guidelines and depending on your technical context you should properly balance the costs. Here is an example with the Ports and Adapters pattern in the context of an ASP.NET application.

Or why analogies with physical work don't work...

Nice exploration of the microcode patching flaw which was disclosed recently. This gives a glimpse at the high level of complexity the x86 family brings on the table.

Translation and localisation is a complex topic too often overlooked by developers. This is a modest list of widespread misconceptions. If you get in the details it get complex fairly quickly.

Nice little paper I overlooked. I agree with it obviously. More tests are not a free pass to let complexity go wild. Architecture and design concerns are still very important even if you TDD properly.

Very interesting discussion weighting the main differences and disagreements between a Philosophy of Software Design, and Clean Code. I read and own both books and those differences were crystal clear, it's nice to see the authors debate them. I'm a bit disappointed at the section about TDD though, I think it could have been a bit more conclusive. It gives me food for thought about my TDD teaching though and confirms some of the messages I'm trying to push to reduce confusion.