Nice and short explanation on the design rules Kent Beck had in mind when devising XP. It still generally applies in my opinion.

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.

A good reminder of the reasons why the organization of your tests shouldn't necessarily match the organization of the application code. You don't want fragile tests, do you?

A long essay but contains a lot of interesting insights. There's definitely more to do design wise to produce software people can really bend to their needs.

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.

A library bringing the mixins concept to C++.

Even if you do use mocks to isolate your tests, at least don't nest them.

A funny way to illustrate the principles behind the SOLID acronym.

This is indeed an excellent way to understand all the roles and the work behind creating a game.

Good explanation of an important design pattern as soon as you have remote calls.

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

There are clearly more to know. But this is a good list already.

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

Yes, there's plenty of room for design in a TDD cycle. This is a good explanation of when it happens and the challenges you can have doing so.

It's meant to be humorous, but this says something interesting about how design and marketing evolves.

Nice post about the practical impacts of Postel's law. It's especially problematic in the case of Open Source software. Companies producing proprietary software even use that to their advantage.

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.

Very nice piece. This is indeed mostly about building organizational knowledge. If someone leaves a project that person better not be alone to ensure some continuity... lost knowledge is very hard to piece back together.

Or why you shouldn't insert an abstraction just for the sake of it. Also clearly not all abstractions are created equal.