1  Why I wrote this book

I spent quite some time thinking about what this book should actually be about.

At first, I thought it would simply be a book about Event Modeling and prooph board. After all, that’s what I’ve been working on for many years. Event Modeling has become the backbone of prooph board and I’ve had countless discussions with customers, colleagues and workshop participants about why it works so well.

The more I thought about it, however, the more I realized that Event Modeling is only part of the story.

This book is really about software engineering.

When I started my career, writing software and understanding the problem were closely connected. Of course we gathered requirements before touching the code, but the real understanding often emerged during implementation. That’s where I noticed inconsistencies in business rules, discovered missing requirements or suddenly realized that my mental model of the problem was incomplete.

Looking back, I don’t think this was unusual. Agile development encouraged exactly this way of working. Build something, get feedback, learn, improve. The feedback cycles became shorter and software became better because of it.

Still, something always bothered me.

Every important insight that emerged during implementation came at a price. By the time I discovered a misconception, I had already written code, discussed implementation details with colleagues and sometimes even built additional functionality on top of an assumption that turned out to be wrong. Sometimes the necessary correction was small. Sometimes it wasn’t. Either way, the thinking happened rather late in the process.

Around 2018, I rediscovered something that, looking back, had probably always been there.

I had already spent several years working with Domain-Driven Design and Event Sourcing. What fascinated me most wasn’t the architecture itself. It was the idea that software could be described in the language of the business. Business events became much more than technical messages. They became milestones in a story that everybody could understand, regardless of whether they wrote code or not.

That naturally led me to Event Storming.

I loved the workshop format. Within a few hours, people with completely different backgrounds could build a shared understanding of a business process. Developers, domain experts, product owners and stakeholders suddenly spoke the same language. Instead of discussing abstract requirements, we talked about things that had happened, things that should happen next and why they mattered.

But something kept bothering me.

After the workshop, what remained?

Many experienced facilitators argued that the board itself wasn’t important. The real outcome was the conversations. Shared understanding had been created, so the artifact had served its purpose and could be thrown away.

I understood the argument.

But it wasn’t enough for me.

If shared understanding is one of the most valuable outcomes of a workshop, why would we throw away the artifact that helped create it? More importantly, how should a team continue building that understanding once development starts and new people join the project months later?

That question stayed with me for quite a while.

My first experiments happened in Miro. I tried to keep Event Storming boards alive after the workshop instead of treating them as temporary artifacts. Gradually they became more than workshop notes. They became design artifacts. They became implementation plans. They became documentation. And the more I worked that way, the more I noticed that I was asking many of the same questions I previously only discovered while writing code.

Changing a model was much cheaper than changing a code base.

I could explore different ideas, validate them with domain experts, discover misconceptions and throw solutions away before they became expensive. Looking back, I think this was the moment when I started practicing what I would later call Spec-Driven Development, although the term didn’t exist for me at the time.

The whiteboard, however, slowly became the limiting factor.

Whiteboards are fantastic for brainstorming because they allow almost anything. Living specifications need something different. They need structure. They need conventions. They need enough consistency that somebody joining the project six months later can understand what they’re looking at without first asking the original author.

That realization eventually led to prooph board.

It started as a better environment for remote Event Storming workshops. Later, Event Modeling became the central modeling technique because it provides the structure I had been looking for. Over time, prooph board evolved from a collaborative whiteboard into a platform for creating and maintaining living specifications.

Then agents entered the stage.

Like many developers, I was fascinated by how quickly they could turn an idea into working software. The first question everybody seemed to ask was how to write better prompts or how to make agents generate better code.

Those are interesting questions.

But I found myself thinking about something else.

Agents don’t discover the solution while implementing it.

They implement the solution we describe.

For decades, implementation had been part of our thinking process. We discovered missing requirements while coding. We challenged assumptions because the code forced us to think through every detail. Agents don’t work that way. They faithfully implement the understanding we already have.

That suddenly made something very obvious.

The engineering discipline I had gradually developed over the previous years hadn’t become less relevant.

It had become essential.

The thinking that used to happen during implementation now has to happen before implementation starts. Somehow, the industry had arrived at the same conclusion, only from the opposite direction.

This is where Spec-Driven Development begins.

A specification isn’t just a document that describes a feature. It’s a place where ideas can be explored, challenged and validated before implementation begins. It captures conversations with domain experts, describes business processes, defines expected behaviour and provides enough context that humans and agents can collaborate without constantly rediscovering the same knowledge.

A good specification doesn’t become obsolete once the first version of the software is shipped.

Software evolves continuously.

The specification should evolve with it.

Over time it becomes the shared understanding that allows a team to extend a system months or years later without reverse engineering their own decisions first.

One thing has also changed since I started working on prooph board.

In the beginning, I spent a lot of time talking about Event Sourcing because it had shaped my own thinking. Today, I rarely start there. Architecture is important, but long before implementation choices become relevant, teams need a shared understanding of the problem they’re trying to solve. They need to understand business processes, user interactions, edge cases, acceptance criteria and the language of the domain. Those conversations are valuable regardless of whether the final implementation uses Event Sourcing, CRUD, microservices or a monolith.

That’s the perspective I’d like to share in this book.

We’ll use Event Modeling as our primary way of thinking about software because I believe it provides an excellent foundation for creating living specifications. But we’ll also look beyond business processes. User interfaces deserve the same level of attention. Rich interactions are often just as difficult to understand and communicate as backend workflows. We’ll use techniques like Breadboarding, wireframe sketches and Given-When-Then scenarios whenever they help us build a better shared understanding of the system.

If there’s one thing I’d like you to take away from this book, it’s this:

Software engineering has never been about writing code.

Writing code was simply the activity that forced us to think.

Today we have the opportunity to separate thinking from implementation. I believe that’s one of the biggest changes our profession has seen in decades. It changes our tools, our workflows and last but not least our role as software engineers.

This book is about making that change a conscious engineering practice.

I hope my experiences over the last years can help you build software that doesn’t just work, but remains understandable, adaptable and enjoyable to evolve for many years to come.