Even the giants are slowly moving back from microservices. DHH has a very cruel way to point it out, still that's true. Let's hope people realize the mistake it was in term of complexity.

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.

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.

Now, this is interesting research. With all that complexity, emergence is bound to happen. There's a chance to explain how and why. The links with the training data quality and the prompts themselves are interesting. It also explains a lot of the uncertainty.

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

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.

A bit of a rant so brace yourselves. Still, it's very much aligned with the current backslash against "everything must be an SPA" trend and makes very good points on how it happened. This indeed turned into a popularity contest based on false premises. Meanwhile... complexity increased dramatically on the web frontend side and the performances are bad for most users.

Good musing about simple code and complexity. We definitely should avoid unwarranted complexity in our code, or at least try to prevent it's spreading.

Indeed we're clearly in a transition period on the Linux ecosystem. If it all comes out to fruition it'll be better for everyone... in the meantime this throws quite some complexity at everyone (in particular for portability and deployment).

A bit heavy handed in the way it tries to paint Root Cause Analysis as evil. Still it has good points about its shortcomings. In particular I appreciate the emphasis on complexity which indeed points to have contributing factors and unexpected outcomes. Definitely things to keep in mind for any postmortem efforts.

A simplified mental model of complexity in software projects. It's not completely accurate but is valuable in the way it is easy to reason about it and probably use it for decision making.

Very important points. This can easily turn a project into a death march with rampant undue complexity. Also the proposed guidelines are simple and seem efficient.

Interesting points about complexity. Indeed it's everywhere the problem is when you start to silently (and unwillingly) worship it... coupled with fear of changes this can only lead to piling more and more complexity in your systems.

Now this is very interesting. An excellent teaser for Herb Sutter's CppCon 2022 talk. Let's see where that goes.

Interesting set of challenges indeed. I think Rust is a bit at a crossroad now. The next few years will be crucial, either they will lead to further adoption or it will stagnate and slowly disappear.

Discusions around a fascinating and very important class of errors in distributed systems.

It feels a bit like cumulating aphorisms and "laws" to prove the point. Still it's nice to know them at least for the general culture.

Interesting view on the state of our industry regarding complexity. Don't despair!

An excellent piece about the links between collapse and complexity. Obviously focuses more on socio-economics systems. Still some of it applies to other fields.