Blog (1 of 16)
-
Hexagonal Architecture vs. Microservices
Bounded contexts deserve boundaries. But a boundary is a code concern, and putting a network between two contexts because you want them separate is a mistake. In-process interfaces are far easier to debug and to keep consistent than network ones, for a concrete reason: one compiler spans both sides and will not let them drift. Nothing spans the network.
Wednesday, 5 August 2026Read more ➞ -
Why 3D Software Visualisation Keeps Failing
A zoomable 3D scene of your architecture, with domains as planes, services as boxes, and data flows as glowing particles, demos beautifully, and WebGL makes it a weekend project. But 3D software visualisation never failed for technical reasons. It fails for perceptual ones, and those have not changed: occlusion, an arbitrary Z axis, label degradation, and depth being one of the weakest visual encodings we know of.
Wednesday, 29 July 2026Read more ➞ -
Feature Flags Over Branches
A while ago I promised to write more about feature flags. Here it is, as one flat rule: develop on main, and use feature flags. Long-lived feature branches are a problem you create for yourself, and most of the structural contortions teams adopt to cope with merge hell are there to solve a process problem with architecture.
Wednesday, 22 July 2026Read more ➞ -
Always Go With a Monorepo
I made this argument to my team again last week, while a neighbouring team was busy splitting their monorepo into around eighty repositories. People reach for a second repository when what they actually want is a boundary, and a repository is a ruinously expensive way to draw a line you can draw for free in the filesystem.
Wednesday, 15 July 2026Read more ➞ -
There Is No Audience-Independent Architecture View
Every team eventually asks for "the architecture diagram", singular, the one picture which explains the system to everyone. That diagram cannot exist, because usefulness and audience-independence trade off by construction. The standards knew this in 1995. The answer is one model, many audience-specific views, and a clear separation between structural views and cross-cutting perspectives.
Wednesday, 8 July 2026Read more ➞ -
Don't Do Code Reviews
In the last post I argued against quality assurance as a separate activity. The same argument applies, almost word for word, to code reviews, and I am even less comfortable making it: at Qafoo we built a code review tool. On an internal product team the asynchronous pull-request review has become the default, and it is the wrong tool for almost everything we use it for.
Wednesday, 1 July 2026Read more ➞ -
Don't Do Quality Assurance
I co-founded a consultancy that sold software quality for roughly a decade. The advice I am most certain about after those years sounds like a contradiction coming from me: do not do quality assurance as a separate activity. The moment a dedicated QA role appears, the developers quietly stop owning the quality of their own work, and that is the wrong direction.
Wednesday, 24 June 2026Read more ➞ -
HTMX and Web Components Instead of React
Our data platform's frontends are catalogs, dashboards, and detail pages: request/response-shaped applications. We build them with server-side rendering, HTMX, and vanilla web components. The question is not "why not React", but which of our actual problems a client-side framework would solve. Walking through the inventory the answer was: none, at a price we would pay for a decade. As a bonus, making components an explicit opt-in turns accessibility from discipline into the default.
Wednesday, 17 June 2026Read more ➞ -
Style the Document, Not a Component Tree
BEM and CSS Modules solve scoping at the cost of making every element a one-off, and a pile of isolated components is not a design language. We style semantic HTML elements directly, constrain every color and distance to CSS variables, and use a small web-component base class instead of a framework. These old-fashioned rules matter more than ever now that LLMs generate frontend code faster than any human team could.
Wednesday, 10 June 2026Read more ➞ -
Nothing Shared, Everything Gained: What It Cost to Finish
I left the start-up world not because I failed, but because I'd optimized for the wrong metric — I was building systems that scaled while being the system that wasn't. This is the post I wasn't sure I'd write, about why "Nothing Shared, Everything Gained" needed me to stop before it could be finished.
Wednesday, 20 May 2026Read more ➞ -
Nothing Shared, Everything Gained: Boring Scales
Every few years our industry discovers a new way to make software development complicated, but most web applications are not technically interesting — the interesting part is the domain. My book is deliberately boring: four layers, strict dependency direction, stateless services, and it worked the same way for five engineers and for seventy.
Wednesday, 13 May 2026Read more ➞ -
Nothing Shared, Everything Gained: The Architecture
The entire architecture in the book fits into one sentence: Controller → Service → Gateway → Storage, with strict dependency direction and one job per layer. A distillation of practical experience, not a new methodology: four concepts that, put into perspective, prevent most structural problems from ever appearing.
Wednesday, 6 May 2026Read more ➞
Subscribe to updates
There are multiple ways to stay updated with new posts on my blog: