This is an ongoing series, but there are good insights about software architecture work in the first few articles. Shows quite well the important tradeoffs and the usual traps.
Indeed, we try to limit the amount of code we need to maintain. But configuration can bring its own complexity and maintenance burden as well.
Nice suggestions on how to structure larger Rust code bases. The proposed error handling is particularly neat and tidy. This is doable in other languages but tends to be more verbose.
Interesting piece which gives some perspective on the path which led to async/await. It seems to omit some pieces of the history to me but that's a minor issue. I like how it points that it indeed led to gradual improvements locally for developers writing their functions, but is overall leading to larger issues in the involved ecosystems.
There's a whole swat of solutions for very lean services. You can go a long way reducing complexity as much as possible. Less infrastructure bills are definitely welcome.
Shows the problem with layer cakes in applications or how you might want to go toward onion architectures.
A bit more nuance in the "how to use the lines of code metric?" debate. Indeed it's not the same if you look at complexity or productivity.
A brief history of word processor formats and how Markdown came to prevail...
Most JS projects end up incredibly bloated indeed. Luckily there are ways to improve the situation.
These are good rules. Take inspiration from them.
Let's not forget where we're coming from and why window managers tend to be merged with display server. It removes some complexity and some latency.
Yes, we have lots of layers nowadays. But you can read them to figure out when something doesn't work like you expect. This is one of the most important skills of the trade.
Probably somewhat self serving so the numbers would need to be confirmed with other experiments. That said that case gives a good idea of the price in terms of complexity and resources when choosing to go for an SPA.
Rampant complexity in software is also a management issue. Are we sure we're rewarding the right things?
No, modularity doesn't imply micro services... You don't need a process and network barrier between your modules. This long post does a good job going through the various architecture options we have.
There are lessons and inspirations to find in how the Vulkan API is managed. The extension system can be unwieldy, but with the right approach it can help consolidate as well.
Interesting essay looking at how systems evolve their schemas over time. We're generally ill-equipped to deal with it and this presents options and ideas to that effect. Of course, the more precise you want to be the more complexity you'll have to deal with.
The complexity and cost in organisations is indeed mostly about coordination. This is a difficult problem and largely unsolved in fact.
Good historical perspective about the attempts to get rid of developers. This never unfold as envisioned. This is mostly about the intellectual work to build artifacts handling the world complexity, and this doesn't go away.
This is a very nice satire website about the problems in our industry. Want to work in a resume driven context? Here is how!