Ever wondered about how Windows 3 was architectured? This is an interesting read. It was really complex though, you can really tell it's in the middle of several transitions.

Indeed, if you can guarantee your materialized views to always be up to date, you might be able to get rid of some caching... and thus some complexity can be avoided.

Indeed, let's not fall for the marketing. It's better to write less code if it's enough to solve actual problems.

A good debunk of that claim we sometime see. Of course the tests need to be designed and you need to have good architecture blueprints to follow, otherwise you'll be in trouble... TDD or not.

Observability is indeed not necessarily easy to fit into a code base. Here is a potential approach to make it easier. I wouldn't use it on a project where we're only logging, but once you add metrics to the mix, this kind of probes can be worthwhile.

This is a good list of guidelines to produce a service which is less of a pain to test locally, deploy and operate. Of course, don't take everything at face value (not all of it aged well) but it's a good source for inspiration.

Or why you should know why you're picking a new tech stack... or not. Don't just blindly follow fashions.

When you realize TDD is about units of behavior... then you can see what can be iterative and what can't in your process. In other word, what is dictated by the problem domain is iterative, what is dictated by system architecture is not. Luckily, the latter is often related to the user experience you're aiming for.

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

Good insight into why Dropbox rewrote its sync engine for desktop clients.

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.