It's All About Semantics

Sep 14 2025

Programming exists in two worlds: the syntactic realm of compilers and the semantic realm of human understanding. While syntax gets code to run, semantics determine whether systems can evolve. Every name, abstraction, and domain boundary creates semantic contracts that either enable or constrain future development. When business concepts contaminate infrastructure layers—like introducing "squads" into an S3 client—semantic pollution occurs, creating rigid systems that resist change. Clean semantic architecture requires disciplined vocabulary, respected domain boundaries, and recognition that we're not just building software, but building languages. The words we choose today become the conceptual framework that shapes what our systems can become tomorrow.

Design Philosophy

 Value Objects for the Win!

Jun 15 2025

Value Objects solve the primitive obsession problem by encapsulating data, validation, and behavior in a single unit. Stop scattering domain logic and start creating more cohesive, maintainable code.

DDD Design

 Lifespan Strategies

Jun 14 2025

Mutability × Time: The Compound Risk series.
\r\nProven techniques for containing the compound risk of mutable state over time. From theoretical patterns to a successful real-world refactoring that eliminated invisible coupling.

Best Practices Design Philosophy

 Invisible Coupling

Jun 14 2025

Mutability × Time: The Compound Risk series.
\r\nWhy components become secretly coupled through shared mutable state. Examines how invisible dependencies erode trust and create debugging nightmares separated by both code and time.

Best Practices Design Philosophy

 The Mutation Timeline

Jun 14 2025

Mutability × Time: The Compound Risk series.
\r\nThe anatomy of object decay over time. Examines how instances progress through Birth, Initialization, Drift, Contamination, and Corruption—and why each stage compounds the previous problems.

Best Practices Design Philosophy

 The Lifespan Paradox

Jun 14 2025

Mutability × Time: The Compound Risk series.
\r\nWhy longer-lived mutable instances become exponentially more dangerous over time. Explores the counterintuitive relationship between object longevity and system reliability through a real-world state management failure.

Best Practices Design Philosophy

 A philosophy of software design - John Ousterhout

May 1 2025

I read A Philosophy of Software Design about 18 months back. It's a well-structured, concise read about managing complexity in software design. I don't think the suggested approaches are applicable in all situations (and John Ousterhout says this himself IIRC), but I recognised a lot of the problems described in the book and found it provided some useful ways to articulate concepts during code reviews (eg. whether adding a shallow function is increasing complexity in a codebase, if complexity can be pulled down into an implementation, or where it's useful to have consistency in the code).

Design Philosophy Software Development

 Design Discovery In Existing Systems

Feb 18 2025

We all want the best design but often that is not directly obtainable. Our tools for understanding systems behaviour may lead us to the abstractions we would want to use in a rewrite but what about the abstractions that exist in the system now? Do they matter? What about the structure? Are there unnamed concepts we can see through the current cohesion and coupling in the system that will help us get to where we need to go? In this talk, Michael Feathers will describe cases where being aware of what currently exists leads to better solutions. We can often leverage what we have instead of building up a domain from a greenfield.

Abstraction Design Systems Video

 Shades of Conway's Law

Oct 14 2024

In short, Conway's Law says any organisation that designs a system will come up with a system design that copies the organisational communication structures.\r\n\r\nOver the years, many individuals rephrased Conway's Law in various ways. Every paraphrase brings new insights and non-negligible consequences. Sometimes they give the impression of contradicting each other. However, in the end, they all come to the same conclusion. The organisation and the system keep each other in balance. Modifying the organisation will have an impact on the system. Modifying the system will have an impact on the organisation. Not considering that will cause friction in the organisation or the system with dramatic consequences.\r\n\r\nTo be competitive as an organisation in the market, and to effectively design the right thing our customers expect us to deliver, we'd better understand and take advantage of this.\r\n\r\nAbout Thierry de Pauw:\r\nThierry is a lean IT Engineer at the fintech startup Abbove. On the side, he founded ThinkingLabs, an advisory firm for optimising IT delivery while reducing stress, burnout and fatigue.\r\n\r\nFrom time to time he is asked to conduct technology due diligence for investors to review the technology capabilities of organisations.\r\n\r\nThierry is a CI/CD advocate and jack-of-all-trades. Instead of balancing quality & delivery, he believes and practices that better quality is actually a way to more and better deliveries.

Conway's Law Design Video

 Visual Agility: Why We Model

Jul 19 2024

Design of complex systems is hard -- wickedly hard! It takes all the cognitive assist we can muster. Trade-offs must be made because there is interaction -- not just interaction among components to create a capability, but interaction among properties. And interaction between the system and its users and containing systems(-of-systems). And more! These systems are evolving -- the more agile, the more we try to take this co-evolution, this learning across boundaries, this symmathesy, into account.

Abstraction Design