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.
One of my favorite of the traditional design patterns in object oriented languages. Now obviously when you get pattern matching in your language... you don't need the visitor pattern anymore.
We're still struggling about how to modularize our code. Sometimes we should go back to the basics, this paper by Parnas from 1972 basically gave us the code insights needs to modularize programs properly.
Another rebuttal of Clean Code. Most of it makes sense if not overdone. There's the usual confusion around the "unit tests" term though, so take that section with a pinch of salt.
This is a good point. Idiosyncrasies are not necessarily a bad thing for naming things. Natural languages are fickle friends, you might need to rely to specific metaphors in order to disambiguate.
Good musing about complexity. Very often we need to move it around, the important question is where should it appear. For sure you don't want it scattered everywhere.
Avoiding boolean parameters in library APIs should be a well known advice by now. Still they should probably be avoided when modeling domain types as well.
Since everything has design choices which imply trade offs. Here is the main issue with PostgreSQL right now. Hopefully it'll get modernized at some point.
Definitely this. Our cognitive capacity is limited, we'd better not deplete it due to complexity before we even reach the core of the problem at hand.
I'm not sure I'm sold on this one. Interesting food for thought but I'll have to mull it over for a while I think. I'm concerned about the performance implications of querying like this.
Nice short post about cohesion in software design. Also gives clue about what proxy we can use to gauge this cohesion.
Interesting exploration of the NT design compared to Unix. There was less legacy to carry around which explains some of the choices which could be made. In practice similarities abound.
Very good article. I wish I'd see more organisations writing such design documents. They help a lot, and that allows to have a way to track changes in the design. To me it's part of the minimal set of documentation you'd want on any non trivial project.