A good list of things to consider when designing systems. And indeed in case of success the result looks probably boring.

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.

The example is maybe a bit on the simplistic side. Still it helps understand why you need to pay attention to the SRP.

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.

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

This is still a valid approach. I regularly encounter cases where the type tag pattern would have been welcome.

The Adaptive Model is a lesser known design pattern. Like any other pattern make sure you are in the right context to introduce it. Especially this one as it can get really verbose. This article shows a refactoring path for moving from imperative logic to adaptive model.

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

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.