It's likely the best explanation of the YAGNI acronym I know. Explains quite well when it applies or not.

A talk from Casey Muratori who is pushing his ideas on software architecture. This one is very interesting on the long history detour it does. Shows well how we keep rediscovering stuff which sometimes go back to the early times of computer science.

And it's not necessarily a problem. It all depends on the goal and context of the API you're building.

And one more... it's clearly driven by an architecture pattern used by all vendors. They need to get their acts together to change this.

This is indeed a metaphor which should be more common in enterprise software.

Nice little post helping advocate for the use of Architectural Decision Records.

Of course, don't take everything at face value here. Still this gives good ideas on how to combine some design and architectural ideas together. The whole thing is not really Rust specific.

Both TDD and design docs complete each other well indeed. They just don't focus on the same activities in the project. That said, both later provide important insights on all the decisions taken to produce some code.

You can't be in the backseat when using those tools. Otherwise you might feel productive by cranking out code but it can't do the essential tasks for you (most notably actual problem solving or architecture thinking). The quality would clearly suffer.

Another way to approach Architecture Decision Records. A different format to try to foster a more collaborative approach.

Apparently this needs pointing out but there's more than async/await out there. Sometimes what you want is a simple event loop. Here illustrated in the Rust ecosystem.

Or how it's possible to expose an object-oriented like API for a data oriented framework without sacrificing on performances.

Didn't know this kind of architectural pattern had a name. Interesting. I wouldn't recommend it in any context though, but one more metaphor to reason with.

Definitely a handy catalog for designing distributed systems.

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

Interesting food for thought. It's important to also approach domain models based on their workflows and events, not just their static relationship graphs.

A good post covering the feature flags concept and the different type of toggles you might have in a project.

Interesting architectural proposal for highly portable C++ based libraries.

Looks like a good set of tips of get more DDD practices in place without the badly understood vocabulary which usually comes with it.

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.