Science, engineering and to some extent management are permeated by the ideas of Cartesian reductionism. Treating phenomena as machines that can be decomposed into their constituent parts layed the foundation to our modern world. Once analyzed and understood, assembling the constituents back together would yield a complete understanding of the phenomena. This is both enticing and arguably successful, however this approach struggles when faced with emergent properties and behaviors of systems.

The assumption that knowing how each component of a system works (micro level) is sufficient to fully understand how a system works as a whole (macro level) is still the default approach in many fields. The paper "Quantifying causal emergence shows that macro can beat micro"¹ provides an interesting model for reasoning about the optimal level of granularity to observe a system. It uses the notion of causal emergence, which is the "zoom level" at which the the causal relationships between the various parts of a system have a stronger correlation - choosing the right "zoom level" will yield the most information. This is interesting because it supplements the idea that focusing only on the study of micro states (which by the way may be more sensitive to noise and subject to degeneracy) does not give the best results in all cases.

If we narrow the scope to the world of technology, distributed systems and the surrounding organizations the observations in the paper make a lot of sense.

After having been through a few incidents I've gained an intuition that knowing how the individual technical pieces of a system work is not sufficient to understand how a system works at a macro scale and how it comes to exhibit certain behaviors. The most interesting incidents actually happen when components and people interact in weird and wonderful ways that take teams completely by surprise.

A system is a whole which cannot be divided into independent parts - Russel Ackoff

The excellent "How Complex Systems Fail"² offers a brief, but very insightful framing to the nature of failure, its evaluation and proximate cause attribution. The core assertion is that a system comprises of people and the technical artifacts that are deployed to achieve a certain objective, and that safety is an emergent property of the system via the interactions of the social and technical elements at play. Failure can seldom be attributed to any single component - clearly odds with a reductionist view of systems (and why exercises like teh 5 Whys are limited).

Dr. Russel Ackoff has a wonderful description of the limitations of reductionism and makes a very compelling argument for systems-first thinking³⁴:

If you have ever built a non-trivial system in an organization you probably know this already: the technical elements may be well defined, however they operate in a messy human organization, that is part of a larger, and even messier market/society. This results in all sorts of interesting, unforeseen and seemingly unreasonable "asks" from the system (AKA stressors in Residuality theory speak).

Technical systems are hyperliminal⁵, its components may exhibit hyperliminal coupling⁶, resulting in the inability of the system's designer to even realize the coupling exists if each component is analyzed separately. Key properties of a system are indeed properties of the whole, and these are lost if the system is taken apart.

The street finds its own uses for things - William Gibson

As we keep building more ambitious technical systems, sometimes in a blissful vacuum⁷, this serves as a reminder for the need to consider the environment where technical systems operate. Failing to do so will result and fragility and negative outcomes.

These days LLMs are capturing the lion's share of media, investor and corporate attention. Judging by the headlines and the gargantuan amounts of funding being mobilized, one would almost think that the tech sector completely pivoted to this technology.

After a well deserved rest for the past few weeks I'm back to my normal routine. One of the ideas I've been toying around with (more on that at some point in the future) benefits from remotely accessing resources running on your local network. If you grew up in the 90s or early 00s you probably remember setting up a NAT in your router to forward certain ports so you could play your favorite game with your friends. Tailscale[^1] has been on my radar for a while so I decided to take it for a spin.

What does unicode, audio processing and admittedly bad early 2000s Internet memes have to do with one another?

In the previous post in the deep dive into unicode series we explored how combining characters like diacritics work. One interesting property of unicode is that it is possible to combine multiple combining characters together.

Programming as Theory Building[^1] is an almost 40 year-old paper that remains relevant to this day. In it, the author (Peter Naur, Turing Award winner and the "N" in BNF[^2]) dives into the fundamental question of what is programming, and builds up from that to answer the question about what expectations can one have, if any, on the modification and adaptation of software systems.

In the previous entry of this series I went through a lightning tour of what is Unicode and provided some details into the various encodings that are part of the standard (UTF-8/16/32). This serves as the baseline knowledge for further exploration of how Unicode strings work, and some of the interesting problems that arise in this space.

"The ecology of the distributed high-tech workplace, home, or school is profoundly impacted by the relatively unstudied infrastructure that permeates all its functions" - Susan Leigh Star

Representing, processing, sending and receiving text (also known as strings in computer-speak) is one of the most common things computers do. Text representation and manipulation in a broad sense, has a quasi infrastructural[^1] quality to it, we all use it in one form or another and it generally works really well - so well in fact that we often don't pay attention to how it all works behind the scenes.

"It is the developer’s assumptions which get shipped to production" - Alberto Brandolini

In parts one and two of this series we explored why software architecture is needed and some of the common pitfalls and failure modes that afflict "architects". This article will go into some of the principles and practices that are part of my toolbox. Very little of this is new and I've tried to link to the original sources so be sure to check the references. If I have misrepresented anything, that's solely on me.

"Two weeks of coding can save you an hour of planning" — Unknown

In part one of this series[^1] I tried making the argument that some degree of software architecture is required, and explored how a naive reading of agile software development practices coupled with organizational incentives create a toxic mix where software design is not valued, leading to a lack of clarity and coherence, viability crushing technical risks being ignored, and creeping and crippling technical debt that slows down software delivery.

“Simplicity and elegance are unpopular because they require hard work and discipline to achieve” — Edsger Dijkstra

Having a role that requires me to sometimes wear the "software architect's" hat at a relatively large organization has given me ample material to digest and reflect on the practice of software architecture, i.e. the design of software systems comprising multiple components owned by different teams. I am hoping to write a small series of posts that articulate (hopefully in an intelligible manner) why some architecture is relevant in our day and age, why it should be a seen as core skill for teams (especially senior+ engineers) and reflect on my own view of the practice of software architecture. Since architecture is part of the broader process of building any non-trivial software system, let's start there.