Nice resource to get started with this important and efficient practice.

Interesting approach. I did quite some of that but without really putting it together like this. It's a nice way to explain it.

Interesting train of thoughts. Indeed we should keep in mind that large scale software is almost always a complex adaptative system, even more so if we don't forget the people developing it and not just focusing on the code. This can give us guidelines on how to organize the development.

Also does a good recap about what a complex system is and how it behaves. Definitely worth a read at least for this.

They were probably using RabbitMQ for the wrong scenario in the first place. That said it's a good reminder that sometimes a simpler architecture is what you want and it can bring benefits.

A nice pattern to know and master in my opinion. At least I turn to it on a regular basis.

This is indeed a phenomenon which I find odd. Everywhere you look, culture seems like it became homogeneous... I don't like this much, but indeed it means it's easy to be distinctive if you want to.

Nice historical perspective from Alan Kay about the MVC architecture pattern.

It's been a while since I dived into reading a Ph.D thesis... I bumped into that one through an article which was trying to summarize it but I wasn't super happy with it. That's why I decided to go to the source.

It's an interesting read, it has the benefit of making a clear difference between complicated and complex from the get go, which is welcome (generally a good sign for me).
If you want the tl;dr it's at the end of page 16:
"we found that differences in architectural complexity accounted for differences in developer productivity of 50%, three-fold differences in defect density, and order-of-magnitude differences in staff turnover".

Note the last point about the staff turnover should be taken with a grain of salt though. It is well explained in the limitations of the study, being a lot in the high complexity areas of the code can also be a sign of higher skills and thus more job opportunities.

Anyway, I think we all suspected some link between complexity and productivity but I always wondered how much. Seeing how the study was done it's definitely not an absolute answer (very thorough and precise, even historical data taken into account over several releases... but in a single company). Still the value is in at last giving us some rough numbers on how far the impacts can go. Thus, the scale of those impacts are potentially huge.

Maybe it's time to stop trying to find rockstar developers or mythical 10x developers (common "leprechauns" of our industry)... Let's focus on tackling undue or uncontrolled architectural and code complexity instead, shall we? Even better if that's done through the use of documented patterns when applicable.

Interestingly, the literature review part gives a few clues about why there is under-investment in architecture in general, or reworking the architecture on long term project. It's unclear to organizations the costs of the undue complexity will carry. It's exactly what this thesis tries to shed light on (see tl;dr above).

Also, it's interesting to see confirmed that the perception of the architectural complexity we have is often wrong when looking at parts in isolation. The relationships need to be transitively mapped to start to grasp the presence of architectural complexity. That's why only coordinated efforts can tackle it, it's almost impossible to tackle for a single developer.

Of course I'd advise reading it in full, that requires investing some time into it though.

Very stimulating, I'd like to apply some of those tools on projects in the wild but I'm not sure there are ready made tools available. Also I'm wondering what we would find if I'd reuse some of those in ComDaAn to work on temporality of changes rather than dependencies. I think this could give interesting insights.

Definitely this. If it's too fancy and fashionable you're likely to pay it in later with the undue complexity it introduced.

Indeed, it's important for architects to get their "hands dirty". Organizations where it's not the case prevent their architects to challenge their assumptions pushing them to stay in their ivory tower. It's a good way for bad decisions to pile up over time.

Very interesting conversation between Uncle Bob and one of the recent critics of his work regarding performance. I like how he admits some faults in the way he presents things and try to improve for later rather than trying to be right. Some people should learn from that. There's clearly a tension between performance and what is described in Clean Code, it'd be pointless to deny it.

Indeed, in some type of projects people tend to turn to Dependency Injection Frameworks a bit blindly (especially true in the Java world). Still there are other patterns which give similar benefits without less headaches. That's worth investigating if this fits your context before picking up a framework.

Interesting position from AMD regarding the race on the next super computers. They're all being caught up by energy efficiency so it'll need to be addressed both at the processor architecture level but also at the software architecture level. How we design our computing tasks will matter more and more.

Interesting explanations of the main drawbacks of microservices. Nothing is magical so you need to know what you loose, in this case this is mostly about increased coordination efforts and latency in feature availability.

Nice demonstration that web frontend can and should be organized like a regular GUI application (like a desktop application for instance). This will bring the same benefits in term of maintainability and modularity.

I'm more and more tempted by this kind of approach. Managing architecture models using code seems fairly neat. That said I wish we'd have better free software tooling for that, I find it still fairly limited. Maybe I should check out the Haskell library which is mentioned.

Excellent piece, looking back to history to justify why microservices are mostly a fad. Check what your needs really are and depending on them pick the right way to decompose the problem or organize your teams.

Good piece. I like how it frames the debate, asking the right questions on where might be the assumptions on how testing is done.

A good set of skills to develop to bring technical changes to a project. It doesn't need to be overwhelming or a fight. If you doubt, if you have empathy and if you slice the proposals it can become doable and help the people around you.

Nice explanation of the Mastodon architecture, how it propagates messages and interactions or how it scales.