Kore Nordmann's Blog

My book describes an architecture in one sentence: Controller → Service → Gateway → Storage.

I have watched a manager give a speech about a value and then, in the next small meeting, act exactly against it.

I have been a happy DigitalOcean customer for years: stable, simple, never a surprise.

A lot of managers want to be friends with the people who report to them.

When a student withdraws consent, their data must disappear from our learning-analytics platform.

I have written a run of posts arguing against multi-repo layouts, long-lived feature branches, reflexive microservices, dedicated QA, blanket coverage targets, and pull-request review.

I watched a team write a careful test suite for a feature, then kill the feature two weeks later because nobody wanted it.

Every data catalog lets you tag a column as PII, true or false.

Dan McKinley's "Choose Boring Technology" gives you a budget of innovation tokens to spend on novel choices.

Bounded contexts deserve boundaries.

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.

A while ago I promised to write more about feature flags.

I made this argument to my team again last week, while a neighbouring team was busy splitting their monorepo into around eighty repositories.

Every team eventually asks for "the architecture diagram", singular, the one picture which explains the system to everyone.

In the last post I argued against quality assurance as a separate activity.

I co-founded a consultancy that sold software quality for roughly a decade.

Our data platform's frontends are catalogs, dashboards, and detail pages: request/response-shaped applications.

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.

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.

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.

The entire architecture in the book fits into one sentence: Controller → Service → Gateway → Storage, with strict dependency direction and one job per layer.

Writing testable code is essential, but writing tests is not — at least not immediately, because comprehensive suites for code that might get cut next sprint are waste, not discipline.

A team that hadn't shipped anything in six months, controllers with NPath complexity causing integer overflows, 2000-line methods, and session arrays nobody understood — and twenty-five days later they were shipping again.

Ten years ago I started writing a book about software architecture and then life happened: I co-founded a company, scaled it to seventy engineers, got acquired, and burned out.