From Six Months of Nothing to Shipping in Weeks

Foreword by Jan Lehnardt

I would like to start by congratulating you on choosing this book. You don't know it yet, but this book is excellent. I've been a professional software developer for nearly thirty years and (humbly) even I learned a few new tricks.

Programming is a complex topic and developers tend to be very opinionated. As a result there are just about as many opinions about how to program correctly than there are programmers. Consequently, there are countless methodologies, acronyms, frameworks and philosophies that all promise the same thing: if you just follow them to the letter, all your problems are solved and all the complexity of software development will be neatly contained.

These things have two things in common: One, they all come with their own nomenclatures and ontologies. They introduce existing concepts with their own names, add relationships between these concepts and once they have got you started, they will continue to exclusively speak in their own self-referential jargon. — Two, they usually can't keep their promise.

I personally have a hard time getting into these because of all the easily confusing language. Why confusing language? Well programming is complex, so any methodology dealing with programming ought to be complex as well, and it needs to be complete so you can embrace it fully, otherwise you won't reap all its benefits.

Building reliable software is hard. No one methodology can prepare you for the realities of shipping working programs to customers who will do unspeakable things to them all while building new features and the next big version and fixing existing bugs and onboarding new team members and losing valuable ones to greener pastures.

This book does the very smart thing of not adding yet another methodology. It does not pretend to have all the answers. Instead, it is a distillation of over fifteen years of hard-won practical experience that you can read in a couple of hours. It gives names to four main concepts that you will have encountered in the past, maybe under different names and puts them into a compelling perspective. The result is not a new methodology but a simple, yet solid architectural foundation for the working practitioner.

This foundation gives you guidelines for building robust products while acknowledging that you will encounter situations (technical and organisational) that don't fit neatly into its narrative. At those points, the book outlines the trade-offs between various options and leaves the decision to you, allowing you to proceed with confidence because you are now equipped for the consequences.

I wouldn't go so far as to suggest a better title for this book would be "The Essence of Programming" because the author chooses but a slice of the wide world of programming, namely building high-performance, scalable, maintainable web apps that earn their development cost in no time and keep teams happy and moving forward. But that's a sizable chunk and this book managed to indeed capture its essence.

The book uses PHP as the example programming language and relies on typical PHP architecture patterns that might not be as prevalent in other ecosystems. But make no mistake, the things you learn translate easily into your working life, even if you work in other languages or in different areas altogether. I started my career in PHP, but have not used it professionally in a long time. While reading this, my brain constantly jumped into projects past and present with ideas of how they could be improved with what I just had learned. I honestly can't wait to get started.

So again, congratulations for choosing to read an excellent book that will teach you things that will improve your every-day programming life for the rest of your career. My only caveat is that I wish I had a book like this nearly thirty years ago.

Jan Lehnardt, Berlin, March 2026

Foreword by Nils Adermann

Jan's foreword congratulates you on choosing this book. I want to congratulate you on something else: choosing to care about architecture at all.

You might wonder whether a book on software architecture still matters in 2026. With AI generating ever more code at increasing speed, isn't the bottleneck elsewhere? I think the opposite is true. The entropy produced by ever-growing volumes of generated code urgently needs mechanisms to rein it in, to steer it into useful, maintainable products. Individual pieces of code may become more short-lived, but the architecture of the systems they compose is what determines whether a team can move fast or gets buried. Getting that architecture right enables significantly more efficient software development, whether the code is written by humans or by an AI agent, which is after all, still trained on the decisions humans made. A shared architectural vocabulary matters more, not less, when the rate of code production accelerates.

Kore introduced me to many of the architectural ideas I rely on daily, and our discussions over the years have shaped how I think about building maintainable software. His experiences consulting at Qafoo and later building Frontastic as CTO regularly informed my own thinking as I built Private Packagist, a B2B SaaS application serving up key infrastructure for thousands of development teams. That means I have seen the ideas in this book from the outside, as someone who absorbed them through conversation and applied them independently, and I can tell you they work.

Running Private Packagist, Composer and Packagist.org puts me in both of the worlds this book describes and illustrates with the complementary and sometimes opposing viewpoints of Paula and Peter. As a product, it is Peter's world: shipping features, responding to customer needs, and making pragmatic trade-offs is what pays the bills. But it also powers infrastructure that developers depend on for their daily work, which pulls toward Paula's rigor. The tension between those two perspectives is real, and it is one of the things Kore gets right. Rather than pretending one approach is universally correct, he gives you the tools to navigate the trade-off consciously.

What I appreciate most about the architecture described here is its honesty. Abstractions leak. Side effects cannot be eliminated. Legacy code encodes valuable knowledge. Kore does not promise that following five building blocks will solve all your problems. Instead, he gives you a shared mental model that makes problems visible and discussable. In my experience, that shared understanding is the single biggest factor in whether a team moves fast or gets stuck.

A topic I feel particularly strongly about is the book's stance on testing. Too many teams test for purity's sake rather than for actual value. Comprehensive test suites, rather than a few tests to check basic fit for purpose, for code that might be thrown away next sprint are not discipline, they are waste. And worse, they create a psychological attachment to code that should feel cheap to discard. Kore's advice to write testable code always but to invest in tests selectively is an honest and practically useful tip. The architecture he describes makes this possible: when your services are stateless and your dependencies are injected, adding tests later is straightforward. You are not gambling, you are deferring an investment until you know it is worth making.

I have seen the patterns in this book work. Experienced developers will recognize many of them, but the book assembles them into a coherent, teachable whole. When a new engineer joins your team, you can hand them this book and know that you will share a common vocabulary for controllers, services, gateways, and the boundaries between them. That common vocabulary is worth more than any individual pattern.

Read it. Discuss it with your team. Adopt what fits. Improve what doesn't. That is the whole point.

Nils Adermann, Berlin, March 2026