Yet another long piece in this interesting and in depth conversation about Bluesky. The fact that it stays civil is called out explicitly and this is appreciated.

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.

A good reminder that genericity can help fight against the rigidity one can accumulate using purely object oriented couplings... but it comes at a price in terms of complexity.

Good explanation on how the agile movement scaled down about design over time in its literature. It's probably its biggest failure. The good thing is that the pendulum is starting to swing in the other direction a bit (that's probably why Beck is now working on a book series on software design).

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 tend to side on the "boring tech" side, but indeed this is a good reminder that what we want is finding the right balance.

I'm obviously not in love with the complexity this type of architecture brings. That being said, this thesis brings an interesting approach to better detect failure scenarios in such systems.

This law is unfortunately too little known. Here is a nice and short primer. Be careful though, it's short but packed with information, might require more reading around the concepts highlighted in this article.

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.

Definitely something architects should do more. Understanding the business needs should be the input to the technical decisions. Otherwise you might just happily build the wrong thing.

Nice return on experience of using a simple stack to serve loads of web requests.

A nice pattern to separate decision from actions in complex algorithms.

Indeed this is not for any environment and projects. So take it with a grain of salt. That said, I think this piece has a core truth to it which is more general. Software architectures shouldn't be considered as something fixed as soon as they are planned, they need to be validated through use and to be prepared to evolve over time as needed.

Since this particular fad apparently doesn't want to die... this is a good reminder about why you want to do something simpler.

Wondering how one can design a coding assistant? Here is an in depth explanation of the choices made by one of the solutions out there. There's quite some processing before and after actually running the inference with the LLM.

Of course documentation, especially one presenting the architecture, shouldn't be neglected. It takes time and skills of course.

Definitely this. The difference between a well performing team and one delivering subpar software is the basics of our trade. Minding your data models, your architectures and the engineering practices will get you a long way.

Interesting thinking about constraints and their rough classification as restrictive or enabling. I also liked how they're tied to complexity.

Good advice yes. Having a rough architecture document in a repository is more than welcome, it's needed to help on-boarding. This is unfortunately not the norm in FOSS projects.