Forem: Leon Pennings

Software Engineering Is Living The Golden Hammer Antipattern — And Everyone Loves It

Leon Pennings — Tue, 14 Apr 2026 05:25:25 +0000

Why the industry simultaneously agrees with Brooks and ignores him — and why it's structured to stay that way

The Paradox Nobody Talks About

Ask any experienced software engineer about essential versus accidental complexity. They will nod. Ask them about Brooks' central argument in No Silver Bullet — that the hard part of software is the conceptual work of understanding the problem, not the mechanical work of expressing it in code. They will nod again.

Then watch what happens when the next project starts.

Someone opens Spring Initializr. Someone proposes microservices. Someone puts Kubernetes in the architecture diagram before a single domain concept has been named. The technology stack is decided in the first week. The business domain is still being understood in month six.

Nobody in that room forgot Brooks. The choice was never really about Brooks.

That is the paradox this essay is about. Not that the industry is ignorant of the problem — but that it is structured to reproduce it perfectly, indefinitely, at enormous and invisible cost.

What Brooks Actually Said

In 1975, Frederick Brooks published The Mythical Man-Month, based on his experience managing the development of OS/360 at IBM. The project was late, over budget, and initially didn't work particularly well. Brooks spent the rest of his career trying to understand why.

The insight most people remember is the coordination problem. Adding people to a late software project makes it later. Nine women cannot make a baby in one month. Communication overhead scales quadratically. You cannot parallelise work that is fundamentally interdependent. Everyone knows this. It shows up in every post-mortem, every engineering blog, every conference talk about why the rewrite took three years instead of six months.

What people remember less clearly is the deeper argument Brooks made in his 1986 essay No Silver Bullet, later added to the anniversary edition of the book.

Brooks drew a distinction between two kinds of complexity in software. Essential complexity is inherent to the problem itself — the rules, the relationships, the invariants, the genuine difficulty of the business domain being modelled. Accidental complexity is everything else — the tools, the frameworks, the infrastructure, the deployment machinery, the coordination overhead introduced by the way we choose to build systems.

His claim was precise and devastating: there is no silver bullet because the hard part of software is essential complexity, and no tool or methodology can compress it. You cannot automate your way out of needing to understand the problem. You cannot framework your way past the conceptual work.

Then he said something that was either ignored or misunderstood: the industry's persistent belief that the next tool, the next methodology, the next architectural pattern will finally solve the problem of software difficulty is itself the symptom of failing to make this distinction.

That was 1986. Since then the industry has produced structured programming, object orientation, UML, SOA, agile, microservices, event-driven architecture, CQRS, cloud-native development, and AI-assisted coding.

Each one arrived as a silver bullet. Each one was greeted with the same enthusiasm. Each one was applied before the domain was understood.

Brooks' own framework predicted every step of it

The Golden Hammer The Industry Forgot To Question

There is a well-known antipattern in software called the golden hammer. It describes the tendency to over-apply a familiar tool regardless of whether it fits the problem. Named after Maslow's observation that if all you have is a hammer, everything looks like a nail.

The modern software industry does not have one golden hammer. It has a coordinated set of them — and they are chosen as a bundle, before the problem is understood, in almost every project that starts today.

The bundle looks like this: a popular framework for the application layer, microservices for decomposition, an event-driven or REST-based communication model, a cloud platform for deployment, and Kubernetes for orchestration. The specific tools vary by organisation and year. The pattern does not vary.

What makes this particular golden hammer different from the textbook antipattern is a crucial property: it is unfalsifiable.

A normal golden hammer eventually gets retired. Something demonstrates it was the wrong tool — the screw still won't turn, the nail bent, the joint failed. There is a moment of visible failure that creates pressure to reconsider.

The modern software stack has no such moment. If the system runs in production, the stack gets the credit. If the system struggles — if changes are expensive, if the team grows endlessly, if understanding the codebase requires months of archaeology — the blame goes to requirements changing, team turnover, business complexity, or simply the nature of software. The stack is never in the dock.

This is not an accident. It is a structural property of how software success is defined. A system running in production passes the only test anyone applies. There is no test for whether it could have been built at a fraction of the cost with a fraction of the complexity. Nobody built that version. Nobody ever does.

The golden hammer persists not because people are lazy or ignorant — but because the thing that should replace it is invisible to every organisational instrument the industry has built.

Agile Was The Correction. Then It Was Captured.

In 2001, the Agile Manifesto proposed something that was, underneath its somewhat vague language, a precise epistemological claim.

Software development is fundamentally a process of learning. You do not fully understand the domain at the start. You build a version of your understanding, expose it to reality — specifically to the domain experts who live in that business every day — and you refine it. Each iteration is not primarily a delivery mechanism. It is a question: did we understand the domain correctly?

The working software at the end of a sprint is not the point. It is the test. The test of whether your conceptual model of the business — your understanding of what the domain actually is, what rules govern it, what concepts belong together — corresponds to reality. Domain experts are not approving features. They are stress-testing your model.

That is what Agile was. A mechanism for continuously refining essential understanding through structured contact with reality.

That is not what Agile became.

What Agile became was a process for efficiently transcribing user stories into framework components. Two-week sprints. Velocity points. Definition of done. Backlog refinement. The ceremonies survived. The epistemology was quietly discarded.

And then CI/CD completed the transformation.

Continuous integration and continuous deployment are genuinely valuable practices for managing the operational complexity of releasing software. But they introduced a subtle and devastating redefinition of what "production ready" means.

Before, production readiness was at least nominally connected to domain correctness — does this system correctly implement the business? After, production readiness means the pipeline is green. Tests pass. Build succeeds. Deploy proceeds.

These are not the same question. A passing test suite validates that the code does what the code was written to do. It says nothing about whether the code was written to do the right thing. Whether the domain concepts are correctly identified. Whether the invariants are correctly enforced. Whether the model reflects the business reality or merely the user story that described one interaction with it.

You can have one hundred percent test coverage and zero domain correctness. The pipeline will be green. The system will go to production. The retrospective will be positive.

The feedback loop Agile promised — between domain experts and the conceptual model being built — was replaced by a feedback loop between the code and its own tests. We optimised the loop while removing the thing it was supposed to validate.

The Sociological Lock-In

So far this looks like an intellectual failure. Engineers and organisations that know better making choices they shouldn't. A problem of discipline or culture that better education might eventually correct.

It is not. It is structural. And the structure actively selects against correction.

Consider how a software project begins. Before a single domain conversation happens, several things must occur. The project must be staffed. That requires a job posting. A job posting requires a technology stack. The project must be estimated. Estimation requires a known architecture. The kickoff deck must be prepared. The kickoff deck needs something in the architecture diagram.

All of these organisational necessities demand a technology decision at the precise moment when the only intellectually honest answer is: we don't know yet. We haven't understood the domain.

That answer is organisationally impossible to give. So the stack gets chosen. Not out of ignorance. Not out of laziness. Out of genuine organisational necessity. The machinery of project initiation requires it.

And once the stack is chosen, it shapes everything that follows. The hiring criteria. The team composition. The onboarding process. The architecture decisions. The decomposition strategy. The system that emerges is not primarily a model of the business domain. It is primarily an expression of the technology choices made before the domain was understood.

This is not the worst part.

The worst part is what happens at the hiring stage.

Conceptual thinking — the ability to reason about what a business concept actually is, what it should own, what it should never be responsible for, where the real boundaries lie — is extremely difficult to assess in an interview. It requires time, domain context, and a level of conversation that most hiring processes cannot accommodate. It does not show up cleanly on a CV.

Tool fluency shows up immediately. Spring Boot, Kubernetes, Kafka, event-driven architecture — these are expressible, searchable, assessable. You can screen for them in thirty seconds. You can test them in a one-hour technical interview. You can verify them with a take-home assignment.

So organisations hire for tool fluency. Not because they don't value conceptual thinking. Because tool fluency is what their hiring process can see.

The consequence is a team that reaches for the familiar tools. The team ships systems using those tools. Those systems run in production. The hiring criteria get validated. The loop closes.

Engineers who push back on premature technology decisions get filtered out at the CV screen, outvoted in the kickoff meeting, or labelled as impractical idealists who don't understand how real projects work. The selection pressure is quiet, consistent, and almost entirely invisible.

When everyone hired thinks the same way, the golden hammer stops looking like a hammer. It looks like engineering.

The Cost Nobody Can See

Here is the claim that cannot be proven and cannot be dismissed.

A system built with a full modern distributed stack — framework, microservices, cloud infrastructure, orchestration — could in many cases have been built far more simply, maintained by a fraction of the team, and been more correct, more stable, and more responsive to business change.

That statement cannot be verified. Because the simpler version was never built. Nobody built it. The team that chose the distributed architecture never built the alternative to compare against. The organisation that approved the budget never saw a competing proposal. The engineers who maintained the system never worked on a well-modelled equivalent.

This is not a gap in the data. It is the mechanism of the problem.

Brooks identified it precisely: most systems are built only once. There is no second system built with different assumptions, run for five years, and compared on total cost of ownership, ease of change, and conceptual correctness. The counterfactual does not exist. Therefore the cost of the wrong choice is permanently invisible.

And here is what makes it truly unfalsifiable: the entire industry is paying the same inflated price. There is no reference point. When every team uses the same stack, incurs the same coordination overhead, grows to the same size, and struggles with the same maintenance costs — those costs stop being visible as costs. They become the definition of what software costs. Normal and wasteful become indistinguishable.

But the difference is not just in cost. It is in what the work actually consists of every single day.

In a team organised around accidental complexity, the daily work is about the technology. Configuring services. Connecting components. Managing framework upgrades. Fixing pipeline failures. Debugging integration issues. Updating dependencies. Understanding the codebase means knowing which service owns which endpoint and how the data flows between them. The business domain is somewhere in there, translated into controllers and DTOs and event schemas, but it is not what the day is about.

In a team organised around essential complexity, the daily work is about the domain. Which concept owns this responsibility. What this rule actually means. What the domain expert said yesterday that changed how they understand the model. The implementation follows from that understanding — and because the model is clear, the implementation is the smaller part of the day, not the larger.

The difference is visible — immediately and without any instrumentation — in the daily standup.

In one team, the language is technical. Spring, Kafka, the pipeline, the service, the endpoint, the migration. Progress is reported in terms of tickets and story completion. The word "business" appears occasionally, usually in the phrase "business requirement."

In the other team, the language is conceptual. The Order, the Invoice, the Payment, what a Shipment is responsible for, whether a Client and a User are really the same thing. Technology appears occasionally, usually briefly, because the implementation of a well-understood concept is rarely the hard part.

You do not need metrics or cost analyses to know which team is working on the right problems. You need one standup.

If every item on the standup is about accidental complexity — go back. Ask what the essential complexity actually demands. Then and only then choose the technology that serves it.

If every garage in the world were built to the standard of a luxury hotel, nobody would know a garage could cost less. The price would simply be what it is. The inflated standard would be the only standard anyone had ever seen.

That is where the software industry is today. Paying Burj Al Arab prices for a garage that needed to store a jar of paint. And maintaining a universal, genuine, unforced consensus that this is simply what garages cost.

Two Rules That Cost Nothing

Most prescriptions for this problem are expensive. Hire differently. Retrain your engineers. Adopt a new methodology. Bring in consultants. Run workshops.

These are not wrong. But they require budget, time, and organisational will that most teams do not have in the moment a project starts.

There are two rules that cost nothing, require no external help, and can be applied starting tomorrow.

Do not choose technology upfront.

Technology enters the project when the domain demands it, not when the kickoff deck needs an architecture diagram. The first weeks of a project produce domain understanding — what the business actually is, what concepts exist in it, what rules govern them. Technology choices follow from that understanding, added only when essential complexity makes them necessary, and only to the degree that it does.

This feels impossible in most organisations. The job posting needs a stack. The estimate needs an architecture. The kickoff slide needs something in the boxes.

Those are real constraints. They are also exactly the organisational machinery that inverts Brooks before the first line of code is written. Recognising that the machinery is the problem is the first step toward not letting it make the decision by default.

Mandate that standups should be about business concepts only. Never technology.

This is the litmus test made into a practice. If someone says "I'm working on the Kafka consumer," the immediate question is: what business concept does that serve, and does that business concept actually require it? If the answer is unclear, the technology choice is premature. If the answer is clear, state the business concept first and let the technology be the footnote it should be.

A standup where every item is about services, frameworks, pipelines, and endpoints is a standup where the team has been captured by accidental complexity. It will feel entirely normal. It will sound like engineering. The terminology will be confident and precise.

But the business domain — the essential complexity that justifies the system's existence — will be invisible. And a team that cannot talk about the business in its daily standup is a team that is not working on the business. It is working on the technology that was supposed to serve it.

These two rules do not solve the problem entirely. The sociological pressures remain. The hiring pipelines remain. The organisational machinery remains. But they create two moments — one at the start of a project, one every single day — where the inversion becomes visible. Where someone can point at the standup and say: we have not mentioned a business concept in three days. What are we actually building?

That question, asked consistently, is more powerful than any methodology.

Closing

The most expensive software is the software everyone agrees is fine.

It runs in production. The pipeline is green. The team is stable. The architecture is recognisable. The job postings write themselves. The onboarding takes three months instead of three days, but that is just how software works. The changes take longer than they should, but the domain is complex. The team keeps growing, but the system keeps growing too. The costs keep rising, but software is expensive.

None of this is inevitable. All of it is a consequence of a single inversion: accidental complexity chosen before essential complexity is understood. A choice made not out of ignorance, but out of organisational necessity, sociological pressure, and the permanent invisibility of the alternative.

Brooks saw it in 1975. Named it clearly. Watched the industry quote him extensively and change nothing.

The golden hammer is not a mistake. It is the product. The template is not a shortcut. It is the destination. The assembly is not the means. It has become the craft.

Two rules. No technology upfront. Standups about the business only.

They will feel radical. They are just Brooks, applied.

Everyone agrees with Brooks.

Then the next project starts.

Fast Onboarding of Software Engineers: The Two Learning Modes

Leon Pennings — Fri, 10 Apr 2026 11:43:42 +0000

There is a persistent belief in software organizations that standardizing on a single framework — Spring Boot being the popular example — makes developers interchangeable across teams. If every system is built the same way, engineers can move between projects with minimal friction.

It sounds efficient. It feels scalable. It is also largely wrong — and understanding why reveals something important about how developers actually learn.

Two Ways to Learn a Codebase

There are fundamentally two modes through which a developer can come to understand a system.

The first is comprehension-based learning. The developer is walked through the core domain concepts — typically in a whiteboard session — and can then trace those exact concepts in the code. The system is legible. Understanding precedes execution.

The second is execution-based learning. The developer runs the system, breaks it, watches it, traces calls through layers. Understanding is assembled gradually from observed behavior. This is the default mode for procedural and layered architectures.

The practical consequence of this difference is not marginal. Comprehension-based onboarding can bring a developer to effective contribution within hours to days. Execution-based onboarding routinely takes weeks to months before a developer can contribute without close supervision.

That gap is not a matter of individual ability. It is a structural property of the codebase.

Pair programming, shadowing, and extensive debugging sessions are not learning strategies in this context. They are compensations — workarounds for the absence of anything readable at the conceptual level. Organizations that rely on them have simply normalized the cost of an illegible system.

Framework standardization does nothing to change this. Recognizing a controller is not the same as understanding why the endpoint exists, what constraints govern it, or what invariants must never be broken. That knowledge lives in the domain — and in most codebases, it lives nowhere at all.

What Comprehension-Based Onboarding Actually Looks Like

In a well-crafted domain model, onboarding follows a different rhythm entirely.

A developer new to the system joins a whiteboard session — 30 to 60 minutes — where the core domain concepts are walked through. They then open the codebase and can trace those exact concepts in the code. Within an hour, the relationships between concepts — what governs what, what depends on what, what is allowed and what is forbidden — form a coherent picture. By the end of the first day, they can participate meaningfully in design discussions, and in many cases begin implementing new functionality.

This is not aspirational. It is the direct consequence of a system that makes its intent legible.

The critical insight is this: new functionality must be grounded in what a system does, not in how it is written. A developer who understands the domain can reason about where new behavior belongs, what rules it must respect, and how it connects to existing concepts — without having traced a single execution path. That is what makes hours-to-days contribution possible. Without it, the developer has no foundation to build from, and execution-based exploration begins — with all the time cost that entails.

First Principles, Not Seniority

This is not about experience level. A junior developer who thinks from first principles — who reasons about what a system is and what it must never do before asking how it runs — will orient just as quickly as a senior. First-principles thinking is a mode, not a career stage. It is the ability to think and talk in concepts and responsibilities, to ask the right questions before reaching for the debugger.

Execution-based systems actively disadvantage this kind of thinking. There is nothing to reason from. The only available strategy is empirical — run it, break it, observe. That favors pattern recognition over understanding, and accumulated exposure over insight. It rewards engineers who are good at navigating complexity rather than those who are good at resolving it.

Over time this has consequences beyond onboarding. The system comes to be understood only by those who have been exposed to it long enough — and institutional knowledge becomes a function of tenure rather than clarity.

Why Most Systems Make This Impossible

The root causes of slow onboarding are almost never the framework. They are structural.

Implicit domain knowledge. Critical business rules are undocumented and embedded in conditionals, naming conventions, and historical decisions nobody questions anymore. New engineers are forced into archaeology before they can contribute. Every answer is buried somewhere in the execution history.

Fragmented business logic. When behavior is spread across controllers, services, and repositories, there is no single place to understand what the system enforces. Every answer requires assembling fragments from multiple layers — which means execution-based exploration is the only path available, regardless of how familiar the framework feels.

Workflow-centric design. Systems modeled around flows — requests, events, pipelines — force developers to reconstruct intent from execution paths. The what is buried inside the how. Reading the code tells you what happens; it does not tell you why, or what must never happen.

These are not framework problems. A Spring Boot application can have a rich domain model. It rarely does, because framework-driven thinking optimizes for how we build rather than what we model — and that trade-off silently pushes onboarding from days into months.

The Domain Model as a Table of Context

A well-structured domain model acts as a compression mechanism for complexity. Core concepts are named clearly. Invariants are enforced in one place. Relationships are explicit.

This gives the codebase something more useful than a table of contents. It provides a table of context: each concept is not just listed but anchored in meaning and relationship. A new developer does not navigate files — they navigate intent. And navigating intent is something a first-principles thinker can do quickly, regardless of how many years they have been writing code.

For this to work, the code must speak the language of the business. If stakeholders say DocumentRequest, the code should not say PayloadDTO. When the language of the domain is reflected faithfully in the implementation, onboarding becomes a translation exercise rather than a decoding one. Translation is fast. Decoding is slow.

A Useful Side Effect: Simpler Code

Systems with rich domain models tend to produce surprisingly simple implementations. This is not accidental.

When complexity is resolved at the conceptual level — when the model clearly captures what is allowed, what is forbidden, and where behavior belongs — it does not accumulate elsewhere. There is less need for elaborate orchestration, framework configuration, or infrastructure glue.

In contrast, systems that lack a strong domain model push complexity into the gaps: coordination logic spreads across components, edge cases get patched rather than modeled, and understanding the system requires tracing runtime behavior rather than reading domain logic. Infrastructure complexity grows not because it is necessary but because the domain complexity has nowhere else to go. This is precisely what makes execution-based onboarding so expensive — the system keeps revealing new layers of implicit complexity the longer you look.

The Role of Frameworks, Properly Understood

Frameworks are not without value in onboarding. They reduce setup friction, provide familiar scaffolding, and standardize infrastructure concerns. A developer who knows Spring Boot will navigate a Spring Boot project faster than a complete stranger would.

But this is surface-layer familiarity. It accelerates the first few hours. It does not touch the weeks that follow.

Onboarding has two layers:

Surface layer — framework, build tools, deployment setup, API conventions. Fast to learn, low in durable value. Framework standardization helps here.

Deep layer — domain concepts, object responsibilities, business rules, architectural boundaries. This is where the weeks-to-months cost lives. Framework standardization does nothing here.

Most organizations optimize the surface layer because it is visible and measurable. They neglect the deep layer, absorb the onboarding cost as a fact of life, and attribute slow ramp-up to individual developers rather than to the structure of their systems.

Conclusion

The question of onboarding speed is ultimately a question of legibility.

A codebase with a well-crafted domain model is legible. A single whiteboard session on the core concepts is enough to orient a developer — because when they open the codebase, those exact concepts are right there, named and structured as explained. The session and the code reinforce each other. From that foundation, a first-principles thinker — junior or senior — can form a complete picture and begin making meaningful contributions within hours to days.

A codebase without one is an execution environment. You learn it by running it, breaking it, and asking the person who wrote it. That process takes weeks. Often months. And it repeats itself every time a new engineer joins.

If you want engineers to move between projects effectively, do not standardize the tools. The tools are not the barrier.

Standardize the clarity of the domain. Make systems understandable rather than developers interchangeable.

That is the real multiplier.

When Distribution Becomes a Substitute for Design — and Fails

Leon Pennings — Tue, 07 Apr 2026 08:41:51 +0000

A lot of modern software architecture—microservices, event-driven systems, CQRS—is not born from deeply understanding the domain. It is what teams reach for when the existing application has become a mess: nobody really knows what’s happening where anymore, behavior is unpredictable, and making changes feels risky and expensive. Instead of asking “What does this concept actually mean and where does it truly belong?”, they ask “How do we split this?”

That is where a lot of modern architecture begins.

Not in necessity.

Not in insight.

But in the growing discomfort of trying to manage software that was never modeled well in the first place.

And because the resulting system still runs in production, the cost of that move often remains invisible for years.

That is one of the most expensive traps in software.

Framework Fluency Is Not Software Design

A lot of developers today are highly fluent in frameworks.

They know how to build controllers, services, repositories, DTOs, entities, integrations, and configuration.

From the outside, that often looks like competence.

But that kind of fluency can be deeply misleading.

Because building software out of familiar framework-shaped parts is not the same thing as designing software well.

The real questions are different:

What is the actual business concept here?
What belongs together?
What behavior is intrinsic to the domain?
What is a real boundary, and what is just an implementation detail?
What rules should be explicit in the model rather than implied by orchestration?

Real domain modeling is not about applying a catalog of patterns. It is the disciplined, often uncomfortable work of discovering what belongs together, what behavior is intrinsic, and expressing those concepts as clearly and cohesively as possible—whether that lives in modules, functions, or simple objects. The goal is conceptual integrity, not architectural ceremony.

Without those questions, software tends to take on a very predictable shape: fat service classes, anemic entities, persistence-first design, procedural workflows, business logic smeared across layers.

The code works. The endpoints return data. The database persists state.

But the system has not really been designed.

It has been assembled.

And that difference matters far more than most teams realize.

Weak Models Create Cognitive Overload

The cost of poor design does not usually show up immediately. At first, the system still feels manageable. A few controllers. A few services. A few repositories. Everything is still “clean.”

But over time, something starts to happen. Business rules accumulate. Exceptions pile up. New requirements interact with old assumptions. Concepts that looked simple turn out to be related in ways the software never captured.

And because there is no strong domain model holding those concepts together, the complexity has nowhere coherent to go. So it leaks—into service methods, orchestration flows, integration glue, persistence logic, special-case conditionals, “helper” abstractions, and coordination code.

At that point, the team starts feeling something very real:

Nobody understands the whole thing anymore.

And that is the crucial moment.

Because once a system becomes cognitively overwhelming, the team has two options:

Option A

Reduce the complexity by improving the model.

Option B

Reduce the scope of the confusion by splitting it apart.

A lot of teams choose Option B.

Distribution Becomes Compensation

This is where architecture often stops being a design choice and starts becoming a coping mechanism.

When the internal model is weak, teams still need some way to create order. And distribution gives them one.

So they introduce microservices, event-driven architecture, CQRS, separate read models, ownership boundaries, queues, and asynchronous coordination.

Distribution, CQRS, and event-driven architecture can have legitimate uses in rare cases of extreme scale or unavoidable organizational boundaries. But in the vast majority of systems, they are not introduced because the domain demands them. They are introduced because the internal model is too weak to provide clarity. What looks like sophisticated architecture is often just confusion hiding behind cleaner service boundaries.

What they are really doing is this:

They are trying to create externally, through distribution, the boundaries they failed to create internally, through design.

And that can work. At least for a while.

A smaller service does feel easier to understand than a large monolith. A separate read model does reduce some friction. A queue does create some local decoupling.

But none of that means the software has become conceptually better. It often just means the confusion has been sliced into smaller containers.

Local Clarity Comes at a Global Cost

That trade is where the real damage happens.

Because distribution absolutely can create local context. A team can say, “This service owns billing.” And that does help.

But it is a much weaker form of clarity than a real domain model. A service boundary can tell you where code lives. A good model can tell you what something is, what it means, what rules govern it, what its lifecycle is, and what relationships are essential.

Those are very different levels of understanding.

And when teams use distribution to manufacture context, they often gain short-term manageability at the cost of long-term agility. Because now the system starts paying the distribution tax: network failure, eventual consistency, contract drift, duplicated concepts, duplicated logic, coordination overhead, deployment complexity, operational burden, and fractured causality.

And perhaps most importantly: lost refactorability.

When the model is strong and cohesive, changing your mind usually means a local refactor—sometimes even a delightful collapse of concepts. When boundaries have been hardened into services, the same insight triggers contracts, versioning, migration scripts, and cross-team coordination. The cost of learning is no longer paid in thought, but in infrastructure and politics.

And in software, changing your mind is not a failure. It is the job.

The Real Cost Is Paid When the Business Learns Something New

This is where badly structured software reveals itself. Not when it is first deployed. Not when the first endpoints work. Not when the dashboards are green. But when the business itself becomes better understood.

Because that is what always happens. Sooner or later, the business learns: these two concepts are actually one thing, this workflow was modeled incorrectly, this rule has important exceptions, this distinction is more important than we thought, or this process should not exist at all.

That is normal. That is what software is supposed to accommodate.

A coherent domain model makes that kind of change survivable. A fragmented, distributed, weakly modeled system makes it expensive.

Note that “coherent domain model” here does not mean the tactical patterns that became associated with DDD—entities, repositories, aggregates, and the rest. Those often added their own accidental complexity. Real modeling is simpler and deeper: it is the ongoing work of refining ubiquitous language and discovering natural conceptual boundaries so that new business insight can be absorbed with minimal violence to the existing code.

Because now the insight has to travel through APIs, queues, read models, event contracts, deployment boundaries, ownership lines, duplicated rules, and partial consistency guarantees. What should have been a conceptual refactor becomes a cross-system negotiation.

And that is where the bill arrives. Not because the domain was inherently impossible. But because the architecture froze yesterday’s misunderstandings into today’s structure.

That is one of the worst things software can do.

Why This So Often Goes Unnoticed

The most dangerous part is that this kind of architecture often looks successful. The system runs. Users use it. The company makes money. So the architecture gets treated as validated.

But “it works” is one of the weakest standards in software. A system running in production proves only that it is viable enough to survive. It does not prove that it is cheap to change, conceptually sound, structurally coherent, or good at absorbing new understanding.

Most teams never get to experience how different software feels when:

Concepts have a single, obvious home instead of being smeared across services
Rules are explicit and enforceable rather than scattered in orchestration and glue code
New business understanding leads to a clean refactor instead of distributed coordination
The system invites insight instead of resisting change

Without that contrast, the pain of weak modeling hidden behind distribution gets normalized as “just how complex software is.”

Often, it is not. Often, it is just the cost of weak design hidden behind architecture.

Final Thought

Much of today’s distributed architecture is not the result of domain insight. It is compensation for the conceptual clarity that was never built into the model. By reaching for separation instead of deeper understanding, teams gain local manageability at the expense of long-term coherence and cheap evolution.

The problem is that the original lack of clarity doesn’t disappear — it just gets distributed. In the end, the same confusion that made the monolith unmaintainable will make the distributed system fail just as hard, only now it’s far more expensive and painful to fix.

This is why so much “sophisticated” architecture is, in truth, just sophisticated coping.

Rich Domain Models: Start with What Is, Not What Happens

Leon Pennings — Sat, 04 Apr 2026 10:18:12 +0000

A lot of software is more difficult to build and maintain than it needs to be.

Not because the business itself is inherently complex.

Not because the requirements keep changing.

But because the software is usually structured around the wrong things: workflows, events, commands, technical layers, frameworks, or current implementation details.

When that happens, the business logic becomes scattered, hard to reason about, and expensive to evolve. The fix is not more patterns, more ceremonies, or more events. The fix is proper domain modelling.

A rich domain model is built by first identifying the core concepts of the business and giving each one clear responsibilities and boundaries. Once that foundation is in place, everything else—events, workflows, persistence, integrations—becomes simpler and more stable.

This is not a new technique or a branded method. It is basic systems engineering done in the right order.

The purpose of domain modelling

Domain modelling is about discovering what exists in the business, independent of how we happen to implement it today.

It means answering a small set of fundamental questions for every important concept:

What is this thing?
What is it responsible for?
What may it know?
What may it decide?
What belongs inside its boundary, and what does not?

These questions come before any talk of events, commands, database tables, API payloads, or user flows. If those questions have not been asked and answered, domain modelling has not actually started. At best, we are only mapping interactions.

Start with responsibilities, not representation

The most common mistake is beginning with representation instead of responsibility.

Teams start listing fields, DTOs, JSON shapes, database columns, or REST endpoints. Those are not the model; they are merely one possible way to represent the model. When you start there, you almost always end up with passive data structures and procedural logic spread across services, handlers, and utility classes.

A rich domain model begins the other way around. The first questions are never “What properties does this object have?” or “What does the request body look like?” They are:

What is this thing?
What does it do?
What is it responsible for?
What should it never be responsible for?

Structure and representation emerge naturally once responsibilities are clear.

A simple way to begin

You do not need extensive workshops, coloured sticky notes, or elaborate frameworks.

The most effective technique is almost embarrassingly simple: put people in a circle of chairs. Tell one person, “You are the Order. What are you? What do you know? What are you responsible for? What should you never do?” Then add the next concept—Client, Invoice, Payment—and let them talk to each other. Let them negotiate boundaries. When something feels wrong, revise the definitions or pull up a new chair for a missing concept.

The medium does not matter—cards, people, puppets, or just conversation. What matters is that you can point at a concept and force it to declare its own identity and responsibilities. When two concepts constantly need to know each other’s internals, the boundaries are probably wrong. When no one knows who should decide something, the responsibility has not been assigned yet. When a concept only exists because a UI flow needed it, it may not be a real domain concept at all.

This is domain discovery. It starts with “What are we about?” and then “Who does what?”—not in the sense of users or actors, but in the sense of the actual participants in the business reality: Client, Order, Invoice, Payment, Subscription, Shipment, Notification.

Why starting with events or workflows feels backwards

Many popular modelling techniques (Event Storming being the most visible) begin with domain events, commands, actors, and processes. They are excellent at mapping what happens and at surfacing integration points. But they are weak at discovering what is.

They describe motion around the business rather than the business itself. A process map can tell you that a payment failed. It cannot tell you what a Payment is, what responsibilities it owns, or whether Invoice resolution belongs to the Invoice, the Order, or a separate Payment concept. It cannot distinguish a Client (the legal/commercial entity) from a User (merely a web-access mechanism for that Client).

Those are modelling questions, and they must come first. Events and workflows are valuable after the core model exists; they should not be the starting point. Otherwise the domain becomes limited to today’s usage patterns instead of reflecting the stable underlying reality.

Aggregates and the danger of procedural models

The concept of “Aggregate” is often presented as a necessary consistency boundary. In practice it frequently becomes a procedural container: a cluster of data that a command mutates and an event is emitted from. When responsibilities have not been properly assigned, those aggregates turn into little more than transaction scripts with a fancy name.

In a rich model the question is simpler: does this concept have a coherent responsibility? If it does, it owns its invariants and decisions. If it does not, no artificial boundary will save it. Objects can collaborate, but they do not need to be artificially clustered just to satisfy technical consistency rules.

Rich domain models make the core simple

A well-defined domain model does not add complexity; it removes accidental complexity.

Consider a typical payment flow. An Order contains Items. An Invoice points to an Order. An Invoice can be resolved by a Payment. A Payment has a type (Online, BankTransfer, etc.). That type determines how execution actually happens.

In a responsibility-driven model this is straightforward:

The Invoice knows it needs to be resolved.
The Payment knows it must execute according to its type.
The type itself (implemented as an enum with a strategy or small implementing classes) encapsulates the variability.

Adding a new payment mechanism tomorrow is a local change inside the Payment concept. No new workshop, no new event storm, no ripple through services. The core model stays stable; only the variable part grows.

Complexity lives exactly where the variability is—not scattered across workflows, services, or “process managers.”

Keep the domain central; push technology to the border

The real architectural decision is not whether a domain object may call a database or invoke an external service. The question is: does this action belong to the responsibility of this concept?

If the answer is yes, the call can live inside the domain object. Technology is not the organising principle. The business meaning is.

When you organise around technology layers instead (controllers, services, repositories, adapters), the business becomes invisible. Every change requires archaeological digging. When you organise around the domain, the business stays transparent and technology becomes replaceable.

Outcomes — short term and long term

A domain model built this way delivers measurable improvements from the very first delivery and compounds dramatically over time.

Short term: Time to first production is usually shorter, not longer. With a rich domain model you know the destination clearly from the start, so you can take the direct route. It is the difference between driving from The Hague to Utrecht on the A12 motorway versus taking the long detour via Amsterdam and the Afsluitdijk. Both paths eventually get you there, but the workflow-first approach feels like continuously driving “somewhat in the right direction” while you figure things out on the fly. By modelling what the business is, you learn faster, decide faster, write less boilerplate, and avoid the lengthy refactoring cycles that come from discovering the business domain later in the project.

Long term: The difference becomes stark — especially in non-CRUD domains such as complex ETL pipelines, logistics orchestration, risk engines, or any system with real business rules and variability.

The “framework-first” or “workflow-first” approach can appear to work for a while. You can wire together services, handlers, and event processors and ship something functional. But as soon as the business evolves — new payment types, new regulatory rules, new integration partners, or changed data flows — the system turns into a web of scattered logic. Maintenance becomes slow, error-prone, and expensive. Changes ripple unpredictably because the business is no longer visible in one coherent place.

In contrast, a rich domain model keeps the stable business reality in the centre. Change stays local. Payment providers, ETL transformations, or logistics carriers can be swapped without touching the core model. Fewer classes, fewer hand-offs, and far less rediscovery work are required. The result is software that is significantly cheaper to keep alive over its lifetime — often by a large margin.

The economic benefit is real, but it is not the goal. It is the natural outcome of doing the engineering work correctly: modelling the domain first, responsibilities first, structure first.

On AI and domain modelling

Modern AI tools are already excellent at helping with the implementation phase. They can generate clean code snippets, suggest conventions, enforce patterns, and accelerate boilerplate work once the model is clear.

But they have no meaningful role in the actual domain modelling itself.

AI cannot sit in the circle of chairs. It cannot negotiate what a concept is, what it should know, or what it should never be responsible for. It can mimic patterns it has seen in other codebases, but it lacks the lived understanding of business reality and the ability to discover stable invariants through dialogue.

Writing the code remains the best mirror for your design. As soon as you start implementing, flaws in the model become visible immediately — that feedback loop is irreplaceable and deeply human. AI can polish and speed up the coding, but it should not be the one discovering or deciding the model. That work still belongs to the people who understand the domain.

Final thought

Basic domain modelling is not complicated. It is simply insisting on answering the most fundamental questions first:

What is this thing?
What is it responsible for?
What belongs inside it?
What should remain outside it?

When those questions are answered clearly, the business becomes visible in the code. Once the business is visible, the system becomes maintainable — from day one and for years to come.

That is not a luxury. For any software expected to live longer than its current tech stack, it is the foundation.

Your software development approach is too expensive and too brittle

Leon Pennings — Thu, 02 Apr 2026 08:14:22 +0000

Most software teams are not struggling because software is inherently chaotic.

They are struggling because they are paying enormous amounts of money to keep the wrong machine barely usable.

That sounds dramatic.

It is not.

In fact, it is one of the most normal things in modern software development.

A lot of systems are built in ways that are:

more expensive than they need to be,
more fragile than they need to be,
harder to change than they need to be,
and harder to reason about than they need to be.

And yet they still get called “well architected.”

Why?

Because in software, there is usually no comparison case.

No control group.

No alternate implementation.

No tractor parked next to the Ferrari.

So if the thing eventually works, the architecture often gets promoted from merely functional to supposedly good.

That is one of the deepest blind spots in software engineering.

And it is how teams end up trying to plow fields with a Ferrari F40.

The Ferrari and the tractor

Imagine you need to plow a field.

You can choose between:

a Ferrari F40, or
a tractor.

This should not be a difficult decision.

The tractor is not glamorous, but it is aligned to the work.

It has:

the right ground clearance,
the right tires,
the right torque profile,
the right durability characteristics,
the right maintenance expectations,
and the right operational shape.

The Ferrari has none of that.

It is a remarkable machine.

It is just the wrong one.

And the mismatch does not merely show up once the work starts.

It shows up immediately.

Because before the Ferrari can even begin to perform badly in the field, someone first has to solve a completely absurd problem:

How do we even make this thing usable for field work?

That is where the real cost begins.

Because now you need compensations.

You need:

custom adaptations,
support structures,
protective workarounds,
non-native operational handling,
specialist maintenance,
and constant care to keep the machine functioning in an environment it was never shaped for.

That is the real problem with a mismatch.

Not just that it performs badly.

But that you now have to build an entire support ecosystem around the fact that it is wrong.

And even that is a cheap mismatch compared to software

In the physical world, the mismatch would at least be visible.

A Ferrari F40 is obviously a terrible agricultural investment.

Even with rough but realistic assumptions, the economics are absurd.

In the physical world, the absurdity would be obvious on a balance sheet. A collector Ferrari F40 trades for millions, while a capable farm tractor costs a fraction of that — with maintenance profiles to match. Using the supercar for field work would not just perform poorly; it would demand absurd custom adaptations before it could even start.

Software hides this mismatch better, which is why teams can run the equivalent for years and still call it maturity.

So yes: in the real world, using a Ferrari to plow a field would already be economically insane.

But in software, the mismatch is often much worse.

Because in software:

the cost is less visible,
the pain is spread over time,
the friction is normalized,
and the organization often has no simpler implementation to compare it to.

That means software teams can spend years operating the equivalent of a Ferrari in a muddy field and still call it “engineering maturity.”

That is the danger.

The uniqueness trap

This is one of the hardest structural problems in software development:

most applications are built only once.

Not once in terms of business purpose, perhaps.

But once in terms of implementation.

A team typically does not build:

one version with a cohesive domain model,
another with CQRS and event choreography,
another with five microservices,

and then compare cost, reliability, comprehensibility, and adaptability over five years.

That almost never happens.

So architecture is rarely judged comparatively.

It is judged internally.

And that means if a system eventually “works,” people often conclude that the architecture must have been reasonable.

But that conclusion is deeply unreliable.

Because there may have been a far cheaper, simpler, more robust, and more truthful way to build the same thing.

No one knows.

Because the tractor version was never built.

That is the uniqueness trap.

And it is one of the main reasons accidental complexity survives so easily in software.

Most software architecture is expensive support structure around a mismatch

This is where the Ferrari metaphor becomes useful.

If someone insisted on plowing a field with an F40, they would not simply “start plowing.”

They would first need to invent a whole support system around the mismatch.

They would need to answer questions like:

How do we prevent the chassis from bottoming out?
How do we maintain traction in mud?
How do we protect components from wear profiles they were never designed for?
How do we attach the wrong machine to the wrong task?
How do we keep it alive under repeated misuse?

In other words:

they would need to build a compensating architecture around the fact that the machine is wrong.

That is exactly what many software teams do.

They choose an architectural shape before they understand the domain, and then spend years building support mechanisms around the mismatch.

That support structure often looks like:

CQRS,
EDA,
orchestration layers,
distributed workflows,
microservices,
command buses,
event buses,
retries,
compensations,
synchronization logic,
observability scaffolding,
deployment choreography,
and framework conventions.

And because all of this is technical work, it often feels sophisticated.

But much of it exists only because the software was shaped incorrectly to begin with.

That is the setup tax of accidental complexity.

Back to Brooks: essential versus accidental complexity

Fred Brooks gave us the cleanest possible vocabulary for this problem decades ago.

Essential complexity

Essential complexity is the irreducible complexity of the business domain itself.

This is the complexity that actually belongs.

Examples:

pricing rules,
eligibility constraints,
shipment state transitions,
reconciliation logic,
metadata rules,
legal behavior,
catalog semantics,
scheduling constraints.

This complexity exists because reality is complex.

You cannot remove it.

You can only understand it, model it, and localize it properly.

Accidental complexity

Accidental complexity is everything introduced by the solution that the problem itself did not require.

Examples:

framework conventions,
architectural ceremony,
messaging choreography,
unnecessary distribution,
layered indirection,
technical orchestration,
compensating workflows,
integration-driven domain shape,
“enterprise” abstraction stacks.

This complexity is not business truth.

It is construction overhead.

And much of modern software architecture is simply accidental complexity with better branding.

The first job of software design is not to choose an architecture

It is to understand the domain.

That should not be controversial.

And yet much of modern software development behaves as if the opposite were true.

Teams routinely begin with questions like:

Should we use CQRS?
Should we use EDA?
Should we split this into microservices?
Should this be event-driven?
Should we separate reads and writes?
Should this be asynchronous?
Should we introduce orchestration?

Those are not first questions.

Those are late questions.

The first question is:

What is the business, really?

Until that question is answered properly, every major architectural choice is at risk of being premature.

And premature architecture is usually just accidental complexity entering the system early enough to become permanent.

The real problem is Pattern-Driven Design

The issue is not that CQRS, EDA, or messaging can never appear in a system.

The issue is that many teams no longer design from the domain outward.

They design from patterns inward.

That is how software ends up shaped by:

command handlers,
event buses,
orchestration layers,
service templates,
and framework conventions

before anyone has actually understood what the business is.

That is not architecture.

That is Pattern-Driven Design.

And Pattern-Driven Design is one of the fastest ways to bury essential complexity under accidental complexity.

Because once the pattern becomes the starting point, the business no longer gets modeled on its own terms.

It gets forced to fit the machinery.

That is not simplification.

That is distortion.

Always start with the domain model

If the goal is to avoid expensive, brittle, overcompensated systems, then the starting point is straightforward:

Always start with the domain model.

Not because every system needs an elaborate object hierarchy.

Not because “DDD” is fashionable.

Not because object orientation is sacred.

But because if you do not start there, something else will define the shape of the software instead.

And that “something else” is usually accidental.

If you do not begin with:

what the business concepts are,
what they mean,
what they are responsible for,
what must always be true,
how they are allowed to change,
and how they interact,

then the system will instead be shaped by:

endpoints,
persistence structure,
framework constraints,
service boundaries,
message flows,
handler conventions,
or transport semantics.

And once that happens, the business is no longer being modeled.

It is being adapted to the machinery.

That is where software becomes expensive and brittle.

A user story is not a model

This is one of the most common and costly confusions in software teams.

A user story is not a model.

A ticket is not a model.

A process diagram is not a model.

A request from the business is not yet the business.

These things describe surface behavior.

They do not necessarily describe the actual structure or semantics of the domain.

That means implementation should never start by merely wiring the request into the chosen architecture.

It should start by asking:

What actually exists here?
What is this concept responsible for?
Which rules belong together?
Which state transitions are valid?
Which interactions are intrinsic?
Which behaviors are essential and which are incidental?

That is the real work of software design.

And the clearest place to do that work is the domain model.

A rich domain model is not overengineering

This is where a lot of modern teams have become confused.

There is a recurring assumption that a rich domain model is somehow “too much.”

But in practice, what often happens is not that the logic disappears.

It simply moves elsewhere.

If the business logic is not in the model, it will end up in:

services,
handlers,
orchestrators,
subscribers,
validators,
workflows,
pipelines,
process managers,
or framework glue.

That is not simplification.

That is displacement.

A rich domain model is not about making software “academic.”

It is about ensuring that the unavoidable business complexity lives where it is:

explicit,
cohesive,
inspectable,
and semantically meaningful.

In other words:

the model should contain the business.

Not the framework.

Not the message bus.

Not the choreography.

Not the deployment topology.

The business.

If the domain is simple, the model will be simple

This is where the usual objection appears:

“But not every system needs a rich domain model.”

Correct.

But that does not weaken the argument at all.

Because the real point is not that every system needs a complex model.

The point is:

every system should begin by discovering whether the domain is simple or complex.

And the correct place to do that is still the model.

If the domain turns out to be simple, then good.

The model will simply remain small and quiet.

That is not failure.

That is successful discovery of simplicity.

But deciding not to start there is a mistake.

Because then simplicity is not being discovered.

It is being assumed.

And assumed simplicity is one of the easiest ways accidental complexity gets invited in.

CQRS and EDA are often compensations for unclear modeling

Here is the part many people will resist.

That is fine.

CQRS and EDA are very often workarounds for bad design or not knowing how to model.

That does not mean they can never appear.

It means they should almost never appear as up-front architectural choices.

That distinction matters enormously.

They can absolutely emerge later as observations in retrospect.

But they should not be adopted as predefined frameworks before the domain has been understood.

Because once that happens, the architecture is no longer responding to the domain.

The domain is being forced into the architecture.

That is backwards.

CQRS is usually an observation, not a design starting point

Properly understood, CQRS is not something you “do.”

It is simply the recognition that:

the model used to change business state is not always the same model best suited for retrieving and navigating information.

That is all.

And sometimes that is perfectly valid.

A search engine like Lucene is a very good example.

The write side may simply persist documents or structured domain state.

The read side may support:

indexing,
tokenization,
ranking,
full-text search,
query optimization.

Those are not the same concern.

That is a natural asymmetry.

That is CQRS as an observation.

But that is very different from deciding on day one that the architecture will have:

command handlers,
query handlers,
buses,
mediators,
folders,
pipelines,
and all the associated ceremony.

That is not domain modeling.

That is accidental complexity pretending to be rigor.

Most CQRS implementations are just CRUD with bureaucracy.

EDA is often the same mistake, but with more latency

Event-driven architecture is often sold as if it were inherently sophisticated.

It is not.

Very often, it is simply a sign that direct responsibility was not modeled clearly enough.

There is a major difference between:

recognizing a domain fact,

and
externalizing causality into a distributed system.

Those are not the same thing.

A domain event can be a useful modeling concept.

But when every business consequence gets turned into:

a message,
a subscriber,
a consumer,
a queue,
a retry policy,
a dead-letter topic,
a compensating process,

then what often happened is not decoupling.

What happened is that one coherent business act was split into multiple technical acts — and the system now needs operational rituals to pretend they are still one thing.

That is not elegance.

That is fragmentation.

If an event is required for correctness, it belongs in the same transaction

This is where a lot of “event-driven” thinking falls apart.

If an event represents something the business considers part of the same completed action, then it should not be externalized into eventual consistency theater.

It should be processed within the same transactional consistency boundary.

Often that means:

same model,
same process,
same database transaction,
same JDBC transaction.

Because if correctness depends on:

retries,
cleanup,
compensating actions,
dead-letter queues,
reconciliation jobs,
or support scripts,

then the architecture has usually split apart something the business still considers one coherent act.

That is not decoupling.

That is a modeling failure disguised as scalability.

The simple rule is this:

If the business says these things are one thing, the software should not split them into many things.

Only effects that are genuinely:

external,
observational,
optional,
or secondary

should be allowed to escape the core transactional boundary asynchronously.

Everything else belongs together.

Microservices are often bad design with Kubernetes

And yes, the same critique applies to microservices.

Microservices are one of the most overprescribed and underjustified architectural choices in modern software.

They are usually discussed in terms of:

scaling,
team autonomy,
resilience,
independent deployment,
ownership.

But that framing hides the actual cost.

Because microservices are not just a deployment decision.

They are a fragmentation decision.

They force teams to commit to distributed boundaries early — often before anyone has proven those boundaries are semantically real.

And once the split is made, the business has to pretend those boundaries are natural.

That is how teams end up with:

cross-service workflows,
distributed invariants,
duplicated concepts,
compensating logic,
service orchestration,
and “eventual consistency” as a lifestyle.

That is not architecture.

That is often just what happens when one cohesive domain gets cut into pieces because “small services” sounded modern.

Logical cohesion comes before physical scale

This is where the usual counterargument appears:

“Yes, but what about scale?”

Fair question.

But scale does not rescue bad boundaries.

It amplifies them.

If you cannot model a business capability coherently in one process, you are very unlikely to improve it by scattering it across twenty.

That is because logical cohesion is a prerequisite for physical distribution.

A coherent system can sometimes be split later if reality genuinely demands it.

An incoherent system does not become better by being distributed.

It just becomes harder to debug, harder to reason about, and more expensive to keep alive.

So yes, scale matters.

But scale is not an excuse to abandon cohesion before you have even found it.

Small is not the goal. Cohesion is.

The phrase “microservice” already biases the conversation in the wrong direction.

Because it encourages optimization for smallness.

But smallness is not the goal.

Cohesion is the goal.

The real objective is:

semantically meaningful boundaries,
high internal density of behavior,
low cross-boundary coordination.

That is very different.

If one business action routinely requires orchestration across multiple internal services, the split is probably wrong.

That is one of the best architectural tests there is.

Because if the business still experiences something as one coherent operation, but the software requires:

service A,
then service B,
then service C,
then retries and compensations if one fails,

then the architecture has not discovered a boundary.

It has manufactured one.

And now it has to manage the damage.

The real cost of framework-first architecture is not implementation. It is drag.

This is where the economics become severe.

Bad architecture is not expensive merely because it takes slightly longer to build.

It is expensive because it creates organizational drag for years.

That drag shows up everywhere.

Slower feature development

Every change now has to move through machinery that was introduced before the business was properly understood.

So even small changes require:

coordination,
contract changes,
handler updates,
event flow changes,
service touchpoints,
deployment sequencing,
orchestration review.

That is not domain complexity.

That is architecture tax.

More defects and harder recovery

When one coherent business action has been fragmented across:

services,
queues,
projections,
retries,
and compensations,

then failure handling becomes vastly more expensive.

The question is no longer:

“Did the business rule execute correctly?”

It becomes:

“Which part of the distributed choreography failed, and what state is the system now in?”

That is a much more expensive problem to solve.

Permanent cognitive overhead

This is one of the biggest hidden costs in software.

A misaligned architecture forces every engineer to carry extra mental load just to understand the system.

Instead of reasoning directly about the business, they must first reason about:

the framework,
the orchestration model,
the service topology,
the event timing,
the deployment shape,
the technical conventions.

That means every change is more mentally expensive than it should be.

And because salaries are the dominant cost in software, cognitive inefficiency is financial inefficiency.

The architecture becomes a second problem

At some point, the software is no longer difficult because the business is difficult.

It is difficult because the architecture has become a second problem layered on top of the first.

The system is now solving:

the business domain, and
the consequences of its own design choices.

That is pure waste.

And because most teams never built the tractor version, they often do not even realize how much of their effort is going into supporting the machine rather than solving the problem.

That is the uniqueness trap again.

The most expensive architecture is not the one that fails immediately

It is the one that:

works just enough,
survives just long enough,
and obscures its own cost just well enough

that nobody ever questions whether the machine was appropriate in the first place.

That is what makes framework-first architecture so dangerous.

It often does not fail loudly.

It succeeds expensively.

And that is much worse.

Because visible failure can trigger redesign.

But expensive success gets institutionalized.

It becomes:

“our platform,”
“our standard architecture,”
“our scalable foundation,”
“our engineering maturity.”

When in reality, it may just be a Ferrari that the organization has spent five years trying to teach to plow a field.

The first responsibility of software architecture is not scalability

It is not flexibility.

It is not “future-proofing.”

It is not pattern compliance.

It is not cloud nativeness.

It is not distributed elegance.

It is this:

to make the essential complexity of the business explicit, cohesive, and understandable.

That is the job.

Everything else comes later.

And if the software cannot explain the business clearly through its model, then it is not well architected — no matter how many services, handlers, events, buses, frameworks, or diagrams surround it.

Because at that point, the architecture is no longer serving the business.

The business is serving the architecture.

And that is why so much modern software is too expensive and too brittle.

A much better default

A better architectural instinct is this:

Do not ask what architecture you can build.

Ask what architecture the domain actually justifies.

And if the answer is:

smaller,
more cohesive,
more local,
less distributed,
less framework-driven,
and more explicit in its model

than current fashion prefers, that is not a sign of immaturity.

It is often a sign that the problem is finally being understood.

The next time a team is asked to “choose an architecture,” the first question should not be:

Which framework?
Which pattern?
Which cloud primitive?
Which service template?

It should be:

What is the business, and what is the cheapest, most coherent way to represent it truthfully?

Because software does not become expensive and brittle by accident.

It becomes expensive and brittle when teams choose machinery before they understand the work.

And from that point on, they do not just have a domain to solve.

They also have an architecture to survive.

That is not engineering maturity.

That is paying interest on a design mistake.

When CI/CD Becomes the Goal: The Quiet Erosion of Engineering Ownership

Leon Pennings — Mon, 30 Mar 2026 06:04:01 +0000

Software delivery has become one of the most ritualized practices in modern development.

Pipelines are longer.

Checks are stricter.

Deployments are more automated.

Dashboards are greener than ever.

Yet in many teams, software has not become more engineered.

It has become more processed.

That distinction matters.

CI/CD was never intended as an excuse to pile machinery on top of weak engineering. It started as a practical response to real problems. But somewhere along the way, much of the industry stopped using it to support strong engineering and began using it to compensate for its absence.

That is where things quietly went wrong.

What CI Originally Solved

The original idea behind Continuous Integration was straightforward.

It was never primarily about pipelines, YAML, or branch policies. It was about forcing reality into the room early.

Developers were expected to integrate frequently — often daily — into a shared codebase. The goal was simple: prevent teams from drifting into parallel worlds and discovering too late that their work didn’t fit together.

That solved a real problem.

Frequent integration forced teams to confront overlap, collisions, ambiguity, and unintended coupling while the cost of correction was still low. But CI did something subtler and arguably more important: it reinforced the team while development was still happening.

Developers didn’t merely discover each other’s work after the fact. They had to continuously adapt to one another’s choices, assumptions, and interpretations of the system in the moment. That pressure was not a flaw. It was the point.

This is how engineering sharpens itself — not by letting everyone disappear into isolated implementation tunnels and comparing answers at the end, but by shaping and correcting each other during the act of construction. Real engineering teams do not just divide work. They reinforce shared understanding.

Original CI made integration a living team concern rather than a delayed administrative event.

That was healthy engineering.

What Continuous Delivery Originally Solved

Continuous Delivery was aimed at a different concern than CI.

Not integration itself, but the path from integrated code to running software.

And to be fair, that was not a fake concern.

But it also was not universally the disaster modern delivery culture sometimes pretends it was.

In many Java systems, deployment was already fairly boring. An application server was stopped, a WAR or EAR was replaced, the instance was restarted, and the system was verified. That was not always elegant, but neither was it some fundamental engineering crisis.

So the real value of CD was not that it magically solved an impossible deployment problem.

Its promise was narrower and more practical: to make the release path more repeatable, more standardized, less person-dependent, and easier to execute consistently across teams and environments.

That is a reasonable goal.

And in some environments, it becomes more than reasonable — it becomes necessary.

Once deployments span multiple machines, rolling restarts, clustered services, or orchestrated server fleets, manual deployment stops being merely inconvenient and starts becoming operationally impractical. At that point, automation is not theater. It is simply the sane way to move software safely and consistently.

That is where CD has real value.

But not all release friction was technical.

In many organizations, a significant part of the “deployment problem” came from the surrounding structure itself: separate infrastructure departments, ticket-driven handoffs, release scheduling rituals, and operational processes that turned even simple deployments into expensive coordination exercises.

That pain was real — but it is important to name it accurately.

Often, the difficulty was not in replacing the software.

It was in navigating the organization around it.

Modern delivery automation did remove a great deal of that friction.

But in many cases, the underlying pattern did not disappear. It simply moved.

Where infrastructure teams once controlled servers and release windows, platform and pipeline teams now increasingly control the mechanics of delivery itself. The form changed. The separation often did not.

And that matters more than it first appears.

Because once the release path is defined by people who do not carry the semantic or business consequences of the software, the pipeline can quietly become a surrogate for ownership.

That is where the trade-offs began.

Where It Started to Go Wrong

The issue is not that CI/CD solved fake problems. The issue is that much of the industry adopted the tooling and rituals while quietly abandoning the engineering assumptions that gave those practices their value.

Once that happened, CI/CD stopped reinforcing good engineering and started compensating for weak engineering instead.

A lot of what now passes for “CI” is no longer continuous integration.

It is deferred reconciliation.

Developers work in isolation on long-lived branches, treating the merge as the first serious moment of contact with the rest of the system. The pain that CI was designed to expose early is now allowed to accumulate until the branch is “ready.” The pipeline creates the illusion of discipline, but the underlying practice has shifted.

The old model forced developers to adapt to each other continuously.

The modern branch-heavy model lets them adapt only at the end.

What makes this regression more serious is that it did not happen accidentally. In many teams, CI was gradually reshaped to serve a different goal: continuous deployment of independently developed changes.

That sounds efficient, but it came with a structural trade-off.

In order to deploy “each feature” continuously, work first had to become isolatable. That pushed development toward branch-based workflows, delayed integration, and feature-level thinking. The unit of progress stopped being the continuously evolving shared system and became the individually shippable change.

And once that shift happened, CI changed with it.

What used to be immediate feedback on a real check-in against the shared codebase became a staged validation process around isolated work. The branch is tested. The pull request is reviewed. The pipeline is green. But the fully integrated system — in motion, under changing conditions, with multiple real changes meeting each other — is often encountered meaningfully much later.

That is not a small process adjustment.

It is a relocation of feedback.

And when feedback moves later, risk moves with it.

The Social Cost Nobody Mentions

This changes far more than code flow.

It changes the social structure of development itself.

Instead of reinforcing each other during construction, developers increasingly become delayed reviewers, test-runners, or approval gates. The shared act of building gives way to a serialized process of isolated work followed by late validation.

That may still produce working software, but it does not produce the same quality of team thinking.

The old model created friction early, while people were still shaping the solution together. The newer model often postpones that friction until after mental commitment has set in. At that point, integration becomes negotiation rather than collaboration.

That is a significant regression.

A team stops behaving like a team.

It starts behaving like a collection of individuals working in parallel and negotiating reality afterward.

And once that happens, the pipeline begins to replace the team as the thing that “validates” software.

That is a dangerous substitution.

Because a team can challenge assumptions, surface ambiguity, and expose misunderstandings while the system is still being shaped.

A pipeline cannot.

It can only tell you whether a predefined process passed.

It cannot tell you whether the software still makes sense.

The Illusion of Delivery Maturity

Continuous Delivery has suffered a parallel fate.

In theory, CD makes deployments safe by making them repeatable. In practice, many teams achieve “safety” by surrounding brittle systems with ever-growing layers of process, abstraction, and automation. The application becomes harder to understand. The deployment model grows more complex. And the pipeline swells to absorb complexity that should never have existed in the software itself.

Eventually, the release system becomes more elaborate than the software it delivers.

This raises an uncomfortable question:

Are we automating a healthy system, or are we automating around an unhealthy one?

If deployment is difficult, brittle, or mysterious, there are usually only two explanations:

The system genuinely operates in a complex environment.
The software was never designed with operability in mind.

The first is sometimes unavoidable.

The second is too often ignored.

Good Deployment Begins in Design

Much deployment pain is treated as the inevitable cost of “modern systems.” In many business applications, that pain is not inevitable — it is designed in.

A well-engineered application should be deployable because it was built to be deployable: operational state kept where it belongs, environment-specific behavior minimized, startup made deterministic, migrations treated as part of the lifecycle, and only what truly needs to vary externalized.

When deployment is simple by design, the need for pipeline heroics drops dramatically.

Automation then becomes what it was meant to be: a way to remove repetition and error from a sound process — not a bandage for an unsound one.

The Dangerous Slide into “Production as Test Environment”

This is where the earlier shift becomes dangerous.

When integration is no longer happening continuously during development, reality does not disappear.

It simply waits.

And increasingly, that reality is encountered much later — often in environments close to or inside production.

This is why so many modern delivery models quietly drift toward using production as their final validation environment. Not because teams explicitly decide to “test in production,” but because the system as a whole often meets changing real-world conditions there more meaningfully than anywhere before it.

That is a very different feedback model from original CI.

Original CI gave teams rapid feedback on check-ins against a shared and continuously evolving codebase. Modern branch-heavy CI/CD often gives rapid feedback on isolated changes, then relies on deployment frequency to surface what only the integrated whole can reveal.

That is not the same kind of safety.

It is simply a different place to discover reality.

Smaller and faster deployments are often presented as inherently safer.

But that is only true if one quietly assumes that the meaning and impact of a change are already well understood.

In practice, that is often exactly what is not true.

A smaller deployment unit may reduce rollback scope or make blame attribution easier, but that is not the same as reducing actual engineering risk. If anything, the opposite can happen: the change is seen by fewer people, discussed less deeply, and integrated less continuously before it reaches production.

That does not reduce uncertainty.

It merely packages uncertainty into smaller increments.

And when production changes multiple times per day, stability itself begins to shrink. The system is only as stable as the scenarios already captured in the automated tests — tests which are themselves usually adapted to the most recent expected path into production.

That creates a dangerous illusion of control.

The software appears validated, but only within the shrinking boundary of what was recently anticipated.

The Semantic Risk Pipelines Cannot See

More importantly, the true impact of a change is often not visible from the code itself.

A seemingly trivial modification for a developer can carry major domain consequences. And a technically substantial change can sometimes be domain-trivial. That asymmetry matters.

Because developers are not domain experts.

They can understand the implementation, but they cannot reliably infer the full business meaning of a change from code alone — not without sustained discussion and feedback from people who actually understand the domain.

And the most dangerous part is that this is not predictable.

It is not true that every change requires deep domain validation.

But it is also not reliably obvious which changes do.

That is exactly why semantic risk cannot be reduced to diff size, deployment frequency, or pipeline confidence.

Many of the hardest failures are not technical crashes or exceptions. They are semantic failures: the system behaves exactly as the code and tests dictate, yet wrongly according to the business.

That is where domain experts matter.

And no amount of deployment frequency changes that fact.

Human Validation Is Not the Enemy of Engineering

One of the stranger modern assumptions is that removing human judgment from the release path is always progress.

It is not.

There is a crucial difference between automating repeatable mechanics and eliminating deliberate validation. Those should never be conflated.

A strong delivery process should automate the mechanical parts — build, package, verify, deploy to controlled environments, reproduce release steps consistently.

That is sensible.

But whether a business-critical change should be exposed to real users is not always a purely technical question. In many systems, it is also a domain question.

Human validation is not a sign of immaturity. Sometimes it is the last remaining sign that someone still understands the difference between technical correctness and business correctness.

That distinction is too often lost.

Application Quality Is Not Generated By Tooling

Part of the problem is that “quality” itself has increasingly been redefined through the lens of tooling.

In many organizations, delivery practices are no longer primarily shaped by engineers with deep ownership of the software and its domain. They are shaped by process-specialized roles, platform teams, and tooling consultants whose authority often comes from familiarity with delivery systems rather than from responsibility for the software’s behavior, design, or business consequence.

That changes what gets optimized.

Quality slowly stops meaning clarity, simplicity, robustness, and domain correctness.

It starts meaning compliance: green pipelines, approved stages, scan completion, branch policy adherence, and process conformance.

Those may be useful signals.

But useful signals can become dangerous substitutes.

And that is how problem analysis gets replaced by cargo cults.

The Real Regression: Loss of Ownership

Underneath all of this lies a deeper problem than pipelines or deployment buttons.

The quiet regression is the loss of engineering ownership.

Modern delivery culture has made it increasingly possible for developers to produce deployable software without truly understanding:

how the system runs
how it is released
how it evolves
how it fails
how it behaves in production
how it fits the business domain as a whole

That is not progress.

That is separation from consequence.

Once that separation occurs, the pipeline stops being a tool.

It becomes a substitute for engineering responsibility.

Pipelines can tell you whether something passed the process.

They cannot tell you whether the software is truly understood.

What Healthy CI/CD Should Actually Look Like

Good CI/CD is not about maximum automation.

It is about preserving engineering discipline while reducing mechanical waste.

That usually looks far less glamorous than modern tooling culture suggests:

Developers integrate continuously into a shared mainline
Incomplete work is handled through discipline and design, not default branch isolation
Build and verification are automated and fast
Deployment to lower environments is repeatable and low-friction
Acceptance happens in a controlled way
Production deployment is simple enough to trust
Human validation exists where domain risk justifies it
The release path is designed to support ownership, not replace it

That is not anti-automation.

It is anti-theater.

And that distinction matters.

The Real Question

CI/CD is not really a tooling question.

It is a quality question.

The real issue is not whether a team has pipelines, feature flags, deployment jobs, or environment promotion stages.

The real issue is this:

Does the delivery process reflect a well-engineered system and a team that understands it — or is it compensating for the absence of both?

That is the question most teams avoid.

Because if the honest answer is the second one, then the pipeline is not a sign of maturity.

It is camouflage.

And that may be the most uncomfortable truth in modern software delivery:

sometimes what looks like engineering progress is really just process growth around declining engineering depth.

CI/CD used as a substitute for the very discipline it was supposed to support.

And once that happens, delivery stops being an expression of engineering quality.

It becomes a process for moving misunderstood software into production more efficiently.

Software Testing: You’re Probably Doing It Wrong

Leon Pennings — Thu, 26 Mar 2026 08:32:29 +0000

Software testing has become one of the most ritualized practices in modern development.

That is not because testing is unimportant. Quite the opposite.

Testing matters.

But in many teams, testing has quietly expanded beyond its actual role. It is no longer treated as a tool for verifying software behavior. It is increasingly treated as a proxy for understanding, a proxy for design, and even a proxy for quality itself.

And that is where the problem begins.

Because testing can verify behavior.

But it cannot replace engineering.

Testing in Software Is a Verification Discipline

At its core, testing in software has a very specific role:

to verify whether a system behaves acceptably under certain conditions.

That is valuable. Necessary, even.

A good test can help answer questions like:

Does this behavior still work?
Does this input still lead to the expected output?
Did this change introduce a regression?

That is where testing is strong.

But notice what testing does not answer:

Is the design coherent?
Is the architecture proportional to the problem?
Is the model a good representation of the domain?
Is this implementation economical to evolve?

Those are engineering questions.

And when teams start treating test suites as if they answer them, behavioral verification gets confused with software quality itself.

That is a costly mistake.

The Math Test Problem

A great deal of modern team testing resembles cheating on a math exam.

Imagine students defining the exam questions during class, together with the teacher, while learning the material. By the time the exam arrives, the goal is no longer to understand the mathematics. The goal is to reproduce the answers that were already agreed upon.

Something very similar happens in software teams.

During refinement, development, or collaborative scenario-writing sessions, expected behavior is often defined in detail in advance. Tests are written, scenarios are formalized, and the team aligns around them.

In theory, this sounds excellent.

In practice, it introduces a subtle distortion:

the implementation target shifts from understanding the business domain to passing the agreed test scenarios.

That is a very different goal.

The result is not necessarily a bad system. But it is often a system optimized for compliance rather than understanding.

And the danger is obvious:

how often is the first interpretation of a business need fully correct?

If the test scenarios are based on incomplete understanding, then all the rigor in the world only helps build the wrong thing more reliably.

Verification Is Not Validation

This is the distinction many teams lose.

Testing is very good at verification:

Did the implementation behave as intended?
Does the system still behave as expected?

But verification is not the same as validation:

Was the right thing built?
Is this actually a fitting solution for the domain?

A system can satisfy every agreed scenario and still be fundamentally wrong.

It can behave correctly while being poorly modeled.

It can produce the expected output while being overcomplicated.

It can pass every acceptance test while solving the wrong problem in the wrong way.

In other words:

A passing test suite proves behavioral agreement—not solution fitness.

And that distinction matters far more than many teams admit.

The Ferrari in the Field

A Ferrari F40 can absolutely move across a field.

It can produce motion. It can get from one side to the other. It can, in the most literal sense, “do the job.”

That does not make it a tractor.

The same is true in software.

A system can satisfy all functional expectations and still be the wrong machine for the domain. It can be too expensive to change, too fragile to extend, too over-engineered for the actual need, or too structurally rigid to survive evolving business requirements.

Testing does not expose that.

Because testing can tell whether the machine moves.

It cannot tell whether it is the right machine.

And that is not a trivial distinction.

That is the distinction between working software and good engineering.

When Tests Stop Following Behavior and Start Following Structure

This is where testing often becomes actively harmful.

If testing is a behavioral verification discipline, then it should limit itself to verifying behavior.

But many modern testing practices go deeper than that.

They start testing:

local call structures
internal collaborations
class-level decomposition
implementation fragments in isolation

At that point, the tests are no longer verifying the system in any meaningful way.

They are verifying the current shape of the code.

That is not the same thing.

And once that happens, the test suite stops protecting change and starts resisting it.

The moment a test depends on how the behavior is achieved instead of what behavior is observed, it becomes a brake on refactoring.

That is one of the most under-discussed quality problems in software teams.

Because now every structural improvement becomes expensive:

rename a collaborator → tests break
merge responsibilities → tests break
simplify orchestration → tests break
move logic to a better abstraction → tests break

Not because behavior changed.

But because the test suite was never really about behavior to begin with.

Why Isolated Class Testing Often Misses the Point

One of the clearest examples of this problem is isolated class testing.

A class exists in code. Therefore, many teams assume it should be testable independently.

But a technical unit is not automatically a meaningful behavioral unit.

That assumption is rarely challenged.

Take something like a PDF information extractor.

That behavior does not meaningfully exist in a vacuum. It depends on:

parsing logic
normalization logic
extraction rules
object interpretation
domain-level decisions

Yet what often happens?

A single class gets tested in isolation.

Its collaborators are mocked.

Its environment is simulated.

Its context is stripped away.

Now the test no longer asks:

“Can the system reliably extract useful information from PDFs?”

Instead, it asks something far weaker:

“Does this one implementation fragment behave under synthetic scaffolding?”

That is not meaningful verification.

That is structural rehearsal.

And the cost is not just conceptual—it is practical.

Because now the test suite is coupled to a local decomposition that may not even survive the next decent refactor.

We end up with a test suite that passes perfectly even if the integration between those fragments is fundamentally broken—because we’ve tested the components, but ignored the composition.

Coverage Is Not Confidence

Test coverage is another example of verification ritual turning into proxy engineering.

Coverage has become a metric in its own right.

Teams report it. Managers ask for it. Pipelines display it as if it were a signal of quality.

But coverage says only one thing:

this code was executed while a test ran.

That’s it.

It does not tell:

whether the test is meaningful
whether important behavior is protected
whether the assertions matter
whether the design is safe to evolve

And yet teams optimize for it anyway.

That leads to the usual absurdities:

getter/setter tests
trivial constructor tests
one-line branch inflation
synthetic assertions written only to satisfy the metric

This is not quality.

It is administrative theater.

Coverage is a measure of execution, not a measure of insight.

And once a team starts chasing the number instead of the confidence, the metric has already failed.

Testing Is Not a Design Discipline

This may be the most important point of all.

Testing can verify whether software behaves as expected.

It cannot tell whether the software is well-designed.

It cannot tell whether:

the abstraction boundaries are good
the model is coherent
the architecture is sustainable
the implementation cost is proportional to the value
future stories will remain easy to add

Those are not test outcomes.

Those are design and engineering concerns.

And if a team replaces those concerns with:

framework templates
scenario scripts
coverage thresholds
pipeline greenness

…then better engineering is not happening.

Judgment is simply being outsourced to artifacts.

That may feel safer.

It may even look more rigorous.

But it is still a substitute for actual thought.

What Testing Is Actually For

Testing does have a real and valuable place.

Used well, testing is for:

verifying externally observable behavior
protecting against meaningful regressions
increasing confidence during change
supporting safe evolution of a system

That is already enough.

Testing does not need to become:

a replacement for design
a replacement for domain understanding
a replacement for architecture
a replacement for engineering judgment

The moment testing is asked to do those things, it becomes overloaded.

And overloaded tools do not become more powerful.

They become more misleading.

The Cost of a Misaligned System

A system does not need to be broken to be expensive.

It only needs to be misaligned.

That is one of the most dangerous illusions in software development: if the system behaves correctly, it is easy to assume the engineering must also be sound.

But a system can pass tests, satisfy stories, and still be fundamentally costly in all the places that matter over time.

It can be:

too expensive to extend
too brittle to refactor
too complex to reason about
too rigid to absorb new requirements cleanly

This is the software equivalent of using a Ferrari F40 to plow a field.

The machine moves.

The task gets completed.

But every future change becomes more expensive than it should be.

That cost rarely appears in the first implementation. It appears later:

in slower feature development
in rising maintenance effort
in increasingly fragile changes
in the growing difficulty of correcting earlier assumptions

And this is precisely where testing, on its own, offers very little protection.

Because testing can confirm that a system still behaves the same.

It cannot tell whether that behavior is now trapped inside the wrong machine.

That is an engineering problem.

And when that distinction is missed, software quality gets reduced to present-day correctness while long-term adaptability quietly deteriorates.

Conclusion

Software engineering has become increasingly comfortable with proxies.

Metrics are used as substitutes for judgment.

Artifacts are used as substitutes for understanding.

Test suites are used as substitutes for design confidence.

And in doing so, many teams create the appearance of rigor while quietly undermining the adaptability of the system itself.

Testing is valuable.

But only when it stays in its lane.

Testing should verify software behavior. It should not define the software, freeze its structure, or pretend to certify its design.

Because the moment verification starts replacing engineering, pipelines may still signal green — but better systems do not follow.

Ferraris get built where tractors would have been enough.

The Mirror and the Machine: Reclaiming Scrum Refinement in the Age of AI

Leon Pennings — Tue, 24 Mar 2026 07:51:20 +0000

Agile was never meant to be a delivery machine. It was meant to be a learning system.

At its core, Agile shortens the feedback loop between business intent and working software—to expose ideas early, validate them quickly, and adapt continuously. The goal was never just to build software, but to discover what the business actually needs by building it.

Somewhere along the way, many teams drifted. User stories became work orders instead of expressions of intent. Refinement became premature implementation design instead of shared understanding. And the feedback loop quietly stretched back to the end of the sprint.

The Problem with User Stories as Work Orders

A good user story expresses intent: What is the user trying to achieve, and why does it matter?

In practice, stories too often look like predefined solutions:

“I want a button in the top right corner to search.”
“Add a ‘costs’ field to each order.”

These constrain the solution space from the start. Better alternatives go unexplored. The system quietly accumulates unnecessary complexity.

What’s missing is the actual problem: Is this about searching, or about finding something quickly? Is this about storing costs, or about understanding profitability?

Without that clarity, we aren’t building solutions—we’re implementing assumptions.

Refinement as Understanding, Not Design

Refinement is where the misunderstanding should be corrected. Yet too many sessions devolve into:

“Where should the button go?”
“What fields do we need?”
“How do we implement this?”

That is early design on incomplete information.

Real refinement focuses first on:

Intent: What is the user truly trying to achieve?
Context: When and why does this happen?
Available information: What does the user already know?
Problem type: Is this a lookup, exploration, or navigation task?

Only after the problem is clearly understood should solution ideas emerge.

A Practical Example: When “Search” Isn’t Search

In an ETL context, a functional manager requests a search feature. On the surface it sounds reasonable. Dig deeper, though, and the real need surfaces:

The manager is often asked by a colleague (or for their own reference) to pull up a specific case. They have only a vague description of the object type and when it occurred. The goal isn’t broad exploration—it’s identification and direct navigation.

Instead of a generic search system, a far simpler solution appears:

Use meaningful, relatable identifiers (a combination of object type and unique ID).
Enable direct navigation via those identifiers.
Add contextual links to related cases.

The result is simpler, faster, and far better aligned with actual usage.

This is refinement at its best: turning vague requests into precise problem definitions.

Mirror Pieces: The First Implementation Is Not the Product

Even strong refinement leaves understanding theoretical until it meets reality. That’s where the first implementation enters—not as a finished deliverable, but as a mirror piece.

A mirror piece is:

A minimal, functional slice of the system.
Built specifically to reflect business intent back to stakeholders.
Deliberately incomplete and open to rapid change.

Its real purpose isn’t immediate value. It answers a more important question: “Is this what you meant?”

By creating mirror pieces early, teams shift from end-of-sprint validation to continuous feedback during development.

Why a UI Is Crucial—Even for Technical Systems

A mirror piece without a UI is often invisible to the business. Raw data, logs, or backend flows require interpretation, reopening the very gap we’re trying to close.

A simple, even rough UI changes everything. It provides:

Observability: What is actually happening in the system?
Navigability: How do entities relate (e.g., DeliveryUnit → PreservationUnit)?
Clarity: Does this match how the business understands the domain?

The UI becomes the event horizon—the meeting point of business intent and technical execution. Without it the system stays abstract. With it, the system becomes a shared language.

Refinement in a Living System

No story arrives in a vacuum. Every new request lands inside an existing system—complete with implemented logic, established flows, and embedded assumptions about how the business works.

Refinement must therefore do double duty: deeply understand the new intent and re-evaluate what already exists.

The first question shifts from “How do we build this?” to “How does this relate to what we already have?”

New stories often reveal deeper truths:

An earlier assumption was incomplete.
A rule was too simplistic.
A flow was designed for a narrower case than reality demands.

This is not failure—it is the system doing its job: exposing gaps in understanding.

When a story interacts with existing behavior, there are typically three paths:

It fits the current model → Simply extend what is already there.
It introduces a variation within the same flow → Isolate the difference cleanly (e.g., using strategy-like patterns) without fracturing the stable core.
It challenges earlier assumptions → Revisit and evolve the underlying model itself.

Treating all three the same—by just adding patches or conditionals—breeds accumulating complexity, duplicated logic, and a system that grows harder to reason about.

In this light, refinement becomes far more than story clarification. It is a checkpoint for system integrity: a deliberate moment to ask, “Does our current system still reflect how the business actually operates?”

Software is not a static machine. It is an evolving mirror of the domain. Every new story offers a chance to confirm, refine, or correct what we thought we knew. Refinement is where that evolution should happen consciously—not accidentally through technical debt.

The Real Cost of Skipping Intent-Focused Refinement

When refinement stays shallow and we build on assumptions instead of understanding, the consequences are predictable:

Misaligned solutions.
Duplicated or conflicting functionality.
Growing technical debt.
Late and expensive rework.
Systems that pass internal checks but fail in real use.

Most importantly, the system stops being a tool for learning and becomes a machine for executing yesterday’s assumptions.

Reclaiming the Feedback Loop

The original promise of Agile was fast, continuous feedback. To reclaim it, we need a mindset shift:

From stories as work orders → to stories as intent.
From refinement as design → to refinement as understanding.
From implementation as delivery → to implementation as a mirror.
From end-of-sprint feedback → to continuous feedback through mirror pieces and early UI.

Conclusion

Software development is often treated as a delivery process. In reality, it is a learning process.

The goal is not merely to build what was asked. The goal is to discover what is actually needed.

Refinement, mirror pieces, early UI, and deliberate validation are not overhead. They are the mechanisms that make genuine learning possible.

Software is not just a tool to serve the business.

It is a mirror that helps the business—and the team—understand itself.

The sooner we look into that mirror, the better what we build will become.

In the Age of AI: Where Does AI Fit?

Looking at refinement as understanding, mirror pieces as feedback, and software as a learning tool, the natural question arises: Where does AI fit?

AI excels at implementation:

Translating well-understood requirements into code.
Generating boilerplate and structure.
Accelerating familiar patterns.

In short: AI operates most effectively in the solution space.

The central challenge in this article lies elsewhere—in understanding intent, interpreting context, challenging assumptions, and discovering what the problem actually is. That remains fundamentally human work.

AI introduces a subtle risk. Because it can generate working code so quickly, it creates an illusion of progress even when understanding is incomplete. If refinement is weak:

AI will still produce code.
The system will still behave as specified.
Tests will still pass.

But the result is simply a faster realization of the same flawed assumptions.

AI doesn’t correct misunderstanding—it accelerates it.

What AI makes unmistakably clear is something that was always true: writing code is often the easiest part of building software. The real difficulty lies in knowing what to build, understanding why it matters, and recognizing when our assumptions are wrong.

That is exactly where strong refinement, mirror pieces, and early feedback matter most.

Within the model described here, AI fits naturally:

Refinement → human-driven discovery.
Mirror pieces + UI → shared validation.
AI → accelerated implementation of what has been learned.

AI lets teams build mirror pieces faster, iterate more quickly, and validate ideas sooner. But it does not replace the need for discovery—it makes that discovery loop more critical, not less.

Final Note

If software development becomes a process of executing predefined solutions, AI will do that exceptionally well.

But if we treat it as a process of learning and deeply understanding a domain, then AI becomes a powerful tool—without ever being the one that asks the important questions.

And those questions are still where the real work begins.

Less Code, Lost Meaning: Why Boilerplate Reduction Misses the Point

Leon Pennings — Fri, 20 Mar 2026 07:46:08 +0000

In modern software development, one theme keeps returning:

reduce boilerplate
write less code
increase conciseness

Frameworks, annotations, and code generators promise cleaner classes and faster development. Tools in ecosystems like Spring Boot emphasize exactly that: less code, less friction, more output.

At first glance, this seems like obvious progress.

But it raises a fundamental question:

Does writing less code actually lead to better software?

The Appeal of Code Reduction

Code reduction is attractive because it delivers immediate, visible results:

fewer lines of code
less repetition
faster initial development

A class with 200 lines becomes 50. Configuration disappears behind annotations. Common patterns are abstracted away.

From a distance, this looks like improvement.

And at the level of syntax, it is.

The Problem: Optimizing the Wrong Layer

Reducing boilerplate optimizes how we write code.

It does not address:

what the code represents
how responsibilities are defined
whether the model is correct

In other words:

It improves expression without improving meaning.

You can have:

perfectly concise code
minimal syntax
elegant constructs

…that still represent a poor understanding of the domain.

And when that happens, the system remains:

hard to understand
fragile under change
difficult to extend

No amount of syntactic improvement fixes that.

The Missing Dimension: The Story

A well-designed system tells a story.

Not in comments or documentation, but in its structure:

objects represent real concepts
behavior lives where it belongs
interactions reflect actual processes

You can read the code and understand:

what the system does and why

This is the “story” of the system.

And it is where most of the value lies.

Why Less Code Doesn’t Mean a Better Story

Reducing code does not automatically improve that story.

In many cases, it does the opposite.

Consider what often happens:

explicit logic is replaced with annotations
behavior is hidden behind framework conventions
configuration replaces clear structure

The result:

less visible code
but more implicit behavior

And implicit behavior is harder to reason about.

You didn’t remove complexity.

You made it harder to see.

The Illusion of Simplicity

Code reduction creates a powerful illusion:

If there is less code, the system must be simpler.

But simplicity in software is not about size.

It is about:

clarity of responsibilities
correctness of the model
predictability of behavior

A small, unclear system is more complex than a larger, well-structured one.

And a concise system with hidden behavior is more dangerous than an explicit one.

When Code Reduction Helps

This is not an argument against reducing boilerplate.

There are clear benefits:

eliminating repetition
removing mechanical code
standardizing common patterns

When applied carefully, code reduction can:

improve readability
reduce noise
allow focus on important parts

But only under one condition:

The underlying model must already be sound.

When It Becomes Harmful

Code reduction becomes problematic when it is used as a substitute for thinking.

When teams focus on:

making code shorter
following framework conventions
reducing visible complexity

Instead of:

modeling the domain
defining responsibilities
understanding behavior

At that point, development becomes:

an exercise in fitting problems into existing constructs

Rather than solving them.

When the Story Disappears

If software engineering increasingly focuses on syntax optimization—on writing less code, faster—then an important question emerges:

Who is responsible for the quality of the story?

Because if we optimize for:

fewer lines of code
more generation
less manual effort

We also reduce something else:

the amount of direct engagement with the model itself

Traditionally, writing code served a dual purpose:

implementing behavior
validating understanding

The act of writing forced decisions:

where does this responsibility belong?
does this concept make sense?
do these rules contradict each other?

Code was not just output.

It was a mirror.

The Role of Friction

Some level of friction in development is valuable.

Not accidental friction—like fighting a framework—but conceptual friction:

needing to define boundaries
needing to resolve ambiguity
needing to make trade-offs explicit

This friction forces clarity.

It exposes:

inconsistencies in requirements
gaps in understanding
misplaced responsibilities

When you remove too much of that friction, you don’t just gain speed.

You lose feedback.

Code Generation as the Endgame

Tools like Claude and similar code generation systems represent the logical extreme of this trend.

They can:

generate large amounts of code instantly
remove almost all boilerplate
translate intent into implementation

From a productivity standpoint, this is remarkable.

But it introduces a new risk:

If code is no longer written, it is no longer used to think.

When “Working” Is No Longer Proof

Traditionally, writing code forced validation.

Each decision had to be made explicitly:

where does this behavior belong?
do these concepts align?
are these rules consistent?

In that process, contradictions surface.

With code generation, that feedback loop weakens.

You describe intent.

The system produces implementation.

And because the result runs, it creates a powerful signal:

It works.

But that signal is misleading.

What you get is not necessarily a system that is correct.

It is a system that appears to work under current conditions.

The Silent Failure Mode

Without active engagement in shaping the model:

contradictions in the domain are not surfaced
responsibilities are not fully resolved
assumptions are not challenged

They don’t disappear.

They remain latent.

And instead of being caught during construction, they emerge later as:

inconsistent behavior
edge-case failures
unpredictable interactions

At that point, the problem is no longer local.

It is systemic.

The Loss of Pressure on the Model

A well-designed system is not just built—it is continuously refined.

Each line of code adds pressure:

on the model
on the boundaries
on the assumptions

Code generation removes much of that pressure.

It allows systems to grow without forcing the same level of scrutiny.

So the model is no longer:

shaped
challenged
corrected

It is merely extended.

From Engineering to Assembly

The risk is not that code generation produces bad code.

The risk is that it enables a different mode of development:

assembling systems without fully understanding them

At small scale, this works.

At larger scale, it leads to:

hidden inconsistencies
fragile structures
systems that behave correctly—until they don’t

And when they fail, they fail in ways that are:

hard to trace
hard to reason about
hard to fix

The Real Risk

The danger is subtle.

The system does not immediately break.

It delivers output.

It passes tests.

It supports current use cases.

But underneath:

the model has never been fully validated.

And over time, that leads to a system that is not truly stable, but:

conditionally correct and fundamentally unpredictable

Closing Thought

Code generation removes effort.

But it also removes something essential:

the act of forcing clarity through construction

And without that:

we risk building systems that don’t fail fast—

but fail late, and fail hard.

The Illusion of Progress: Why Tooling Can’t Replace Engineering

Leon Pennings — Wed, 18 Mar 2026 14:10:52 +0000

Walk into almost any modern enterprise Java codebase and you’ll see the same pattern: controllers, services, repositories, configuration, and a dense web of injected dependencies—often built on frameworks like Spring Boot.

It works. Requests flow through the system. Data is persisted. Features get delivered.

By most organizational standards, this is considered a success.

But there’s a fundamental question almost never asked:

Is this system well engineered—or does it merely appear to work?

The Industry’s Blind Spot

Software development suffers from a unique problem: we almost never get to compare two fundamentally different approaches to the same system.

One system is built by Team A, using framework templates
Another is built by Team B, using a strong conceptual model

Different teams, different timelines, different constraints.

So when a system “works,” we assume:

the approach must be valid

But we never see:

what that same system could have looked like with a better model

That absence of comparison creates a blind spot—one where “working software” is mistaken for “well-designed software.”

The Rise of Template-Driven Development

Frameworks like Spring Boot didn’t become dominant by accident.

They offer:

immediate productivity
standardized structure
fast onboarding

They allow teams to produce output quickly—often without deeply understanding the domain.

And that’s where the shift happens.

Instead of asking:

What is the correct model of this domain?

Teams start asking:

Where does this go in the template?

At that point, development turns into something else entirely:

Stenography. Translating user stories into predefined technical slots.

The result:

large amounts of integration code
thin or absent domain logic
systems that function—but are difficult to evolve

The Cost You Don’t See

Systems built on heavy frameworks don’t usually fail.

They degrade.

Not in obvious ways, but in how time and effort are spent.

At first, development feels fast:

scaffolding is generated
endpoints are wired
persistence is handled

Features appear quickly.

But over time, a shift happens.

The system is no longer primarily about automating the business domain.

It becomes increasingly about maintaining the technical environment around it.

The Hidden Shift in Effort

In many enterprise systems, a large portion of engineering effort is spent on:

upgrading frameworks (e.g. annual cycles in Spring Boot)
adapting to breaking changes
resolving dependency conflicts
aligning with new conventions and best practices
re-testing behavior that should not have changed

This is not business value.

It is tooling maintenance.

Over time, the ratio shifts:

Less effort goes into improving the domain.

More effort goes into keeping the system compatible with its own foundation.

In extreme cases, the majority of work is no longer about what the system does, but about what it runs on.

Integration Becomes the System

As frameworks evolve, systems accumulate:

layers of adapters
configuration overrides
compatibility fixes

The result is a codebase where:

most code connects things
very little code expresses the domain

At that point:

The system is no longer a model of the business.

It is a network of integrations.

The Upgrade Trap

Modern frameworks evolve continuously.

Each upgrade promises:

improvements
performance gains
new capabilities

But each upgrade also introduces:

migration effort
subtle behavioral changes
renewed testing cycles

Individually, these seem manageable.

Collectively, they create a constant background load.

A system that was supposed to simplify development now requires continuous adaptation just to remain operational.

Loss of Focus

The most damaging effect is not technical—it’s directional.

When most effort is spent on:

frameworks
infrastructure
compatibility

Then the business domain becomes secondary.

Teams stop asking:

How do we model this problem better?

And start asking:

How do we make this work within the framework?

At that point, the system is no longer driven by the domain.

It is driven by the tooling.

The Real Cost

This cost rarely appears in metrics.

It shows up as:

slower feature delivery over time
increasing effort for simple changes
growing system fragility
loss of clarity about what the system actually does

And most critically:

A large portion of engineering capacity is spent on work that does not move the business forward.

The Alternative: Start With the Model

There is another way to build systems—one that doesn’t start with frameworks or templates.

It starts with a different premise:

Software development is primarily a modeling activity.

Before writing code, you ask:

What are the core responsibilities?
Where does behavior belong?
What are the invariants of the system?

From there, you build:

rich domain objects that own behavior
clear boundaries that prevent concern leakage
explicit lifecycles that reflect real interactions

In such a system:

objects are used, not orchestrated
behavior is invoked, not assembled
structure reflects meaning, not framework conventions

“But What About Wiring?”

A common assumption in enterprise development is that systems require extensive wiring:

dependency injection
service composition
configuration graphs

But this is often a symptom, not a necessity.

When responsibilities are well-defined and localized:

objects don’t need to be assembled dynamically
behavior doesn’t need external orchestration
lifecycle can be handled at clear boundaries

Instead of wiring a system together, you:

define objects that already make sense together

Infrastructure concerns—like persistence or messaging—can be handled through:

decorators
well-defined interaction boundaries

Not scattered across the system.

The result is not “no composition,” but:

composition that is internal, stable, and invisible

Why This Feels Slower (But Isn’t)

Taking time to understand the domain can feel like a delay.

But consider the alternative:

building quickly in the wrong direction
discovering mismatches later
restructuring under pressure

It’s the difference between:

planning a route before driving
or heading “roughly east” and hoping to arrive

The first appears slower. The second is slower—just not immediately.

The Real Constraint

If this approach is so effective, why isn’t it the norm?

Because it depends on something rare:

Strong conceptual thinking

Framework-driven development scales because it:

reduces decision-making
standardizes structure
works with uneven skill levels

Conceptual modeling does not:

it requires alignment
it requires discipline
it requires engineers who can think in systems

So organizations optimize for:

predictable output

Instead of:

optimal design

The Resulting Illusion

This leads to a persistent illusion in the industry:

Systems built with heavy tooling are seen as “modern”
Systems built with strong models are seen as “overthinking”

Because one produces:

immediate, visible progress

And the other produces:

long-term structural integrity

But without a direct comparison, the difference remains invisible.

A Different Standard of Success

If we want to build sustainable systems, we need to change the definition of success.

Not:

“Does it work?”

But:

How easy is it to understand?
How localized is change?
How much of the code reflects the domain vs integration?

Because ultimately:

A system that merely works today can become a liability tomorrow. A system that is well modeled continues to work—even as it evolves.

Closing Thought

Tooling is not the enemy.

But it becomes a problem when it replaces the very thing it was meant to support:

Engineering.

Frameworks can accelerate implementation. They cannot replace understanding.

And without understanding, we’re not engineering systems.

We’re assembling them—and hoping they hold.

The Ghostwriter, the House Builder, and the Missing Domain Model Walk Into a Bar

Leon Pennings — Mon, 16 Mar 2026 06:57:08 +0000

Software development is often described as “building systems”.

But there are two professions that might describe the job much better: writing a book and designing a house.

Both involve creating something coherent out of many parts.

Both require understanding purpose before execution.

And both reveal a common mistake that appears surprisingly often in modern software development.

To see why, imagine two professionals: a ghostwriter and a house builder.

The Ghostwriter Version of Software Development

Imagine you hire a ghostwriter to write a book based on your ideas.

You send them fragments:

a story about a childhood memory
a chapter about leadership
a few anecdotes about business
a paragraph about innovation
a repeated explanation of a concept you already mentioned earlier

A bad ghostwriter simply writes everything down exactly as provided.

The result is technically correct. The grammar is fine. The sentences are clear.

But the book becomes a mess:

topics overlap
concepts repeat
arguments contradict each other
the narrative jumps randomly between ideas

Nothing ties the material together into a coherent story.

The ghostwriter has focused on transcription, not authorship.

Unfortunately, software development is sometimes practiced in a very similar way.

A team receives a series of user stories:

“Customers should be able to create orders.”
“Orders can have discounts.”
“Admins can modify customer data.”
“Orders must be validated before submission.”

Each story is implemented somewhere in the codebase. A controller here, a service there, a validation rule somewhere else.

Every story is technically implemented.

But over time the system starts to show symptoms:

business rules appear in multiple places
behavior becomes inconsistent
changes require touching many unrelated components
nobody is entirely sure where certain logic belongs anymore

The system becomes the equivalent of the badly written book: a collection of fragments without a coherent narrative.

The problem is not coding skill. The problem is the absence of structure.

The House Builder Version of Software Development

Now imagine designing a wooden house.

But instead of starting with how people will live in it, the builders start with their tools.

The plumber places the bathroom where the pipes are easiest to install.

The electrician places the kitchen where wiring is convenient.

The carpenter builds bedrooms wherever the structure is simplest.

Each professional does excellent work.

The plumbing is perfect.

The wiring is flawless.

The construction is solid.

But when the house is finished, something feels very wrong.

The dining room is on the opposite end of the kitchen.

The shower is installed in the kitchen because the pipes were already there.

The bedrooms are nowhere near the bathroom.

Every part of the house is technically well built.

But the house does not work as a house.

No one began by asking the most important question:

How will people live here?

The same thing happens in software development when architecture is driven primarily by tools and technologies.

Discussions revolve around:

frameworks
infrastructure
microservices
deployment pipelines
cloud platforms

All important tools.

But they are construction techniques, not design principles.

Without understanding how the system is supposed to behave as a whole, even the best tools can produce a system that is technically impressive but conceptually broken.

What’s Missing: Coherent Design

Both examples expose the same underlying problem.

The ghostwriter fails because they never discovered the story.

The house builders fail because they never understood the purpose of the house.

In software engineering, the equivalent is failing to understand the domain.

User stories describe fragments of behavior.

But if every story is simply implemented as-is, the system slowly loses coherence.

Engineering cannot start with implementation. It must start with understanding.

What activities exist in the domain?

What concepts matter?

What rules must always hold?

Where should responsibilities live?

Only when those questions are answered does the structure of the system begin to emerge.

Enter the Domain Model

This is where the domain model becomes essential.

A domain model acts as a responsibility localizer and logic contextualizer.

Instead of scattering behavior across the codebase, the model provides structure:

concepts are represented explicitly
rules live with the concepts they govern
responsibilities have clear homes

When a new user story arrives, the question is no longer:

“Where should we add this piece of code?”

Instead the question becomes:

“What does this story mean for our understanding of the domain?”

Sometimes the answer is simple.

Sometimes it requires adjusting the model itself.

But the goal remains the same: preserve conceptual integrity.

Without that integrity, software inevitably turns into the badly written book or the badly designed house.

The Risk of AI

AI-assisted coding is incredibly powerful.

It can generate code, implement features, suggest refactorings, and remove enormous amounts of repetitive work. Used well, it is an enormous productivity accelerator.

But AI is strongest at local implementation.

It excels at doing exactly what it is asked: implementing a function, adding a feature, modifying an existing piece of code. In that sense it behaves very much like the literal ghostwriter who writes the paragraph that was requested, or the contractor who builds a perfectly constructed room.

What AI does not replace is modeling the domain.

It does not determine:

what the core concepts of the system should be
where responsibilities belong
how rules should be structured
how the system should reflect the purpose of the business

Those decisions require understanding intent and discovering structure. They are design activities.

AI can dramatically accelerate the technical execution of a system. But it cannot replace the need for coherent design.

Otherwise we risk the same outcomes as before: a technically correct book without a story, or a well-built house that no one can live in.

Conclusion

In an interesting way, the rise of AI coding tools highlights something that has always been true in software development.

Many teams have already been operating primarily at the level of feature implementation, while the deeper design work was often implicit, inconsistent, or missing entirely.

Custom software is essentially a one-off prototype. There is no reference design to compare it to. There is no second version of the same system built by another team. There is only one implementation: the one that ends up running in production.

That makes design mistakes difficult to spot early.

A book with a broken narrative may only reveal its problems once the entire manuscript is finished.

A badly designed house may only reveal its flaws once people try to live in it.

Software is no different.

Which is why the design phase — understanding the purpose of the system and shaping a coherent domain model — cannot be skipped.

The ghostwriter must understand the story.

The architect must understand how the house will be lived in.

And the software engineer must understand the domain before writing the code that brings it to life.

The Two Levels of Software Development — And Why Most Enterprise Applications Fail Over Time

Leon Pennings — Tue, 10 Mar 2026 07:39:44 +0000

There are two fundamentally different levels in software development.

Level 1 — Getting the system to run

At this level the goal is straightforward:

the application compiles
the system deploys
features behave as expected
users can operate the software

If those conditions are met, the project is considered successful.

Most modern frameworks are extremely good at helping teams achieve this level. A stack such as Spring Framework provides a ready-made structure for building applications quickly: web infrastructure, dependency injection, persistence integration, configuration management, and more. With the right templates and tooling, teams can produce a working system in relatively little time.

Level 2 — Keeping the system economically evolvable

The second level is far harder.

Once the system has been running for several years, the real question becomes:

Can developers still reason about the business rules?
Can features be added without breaking existing behavior?
Does the cost of change remain predictable?

This is the level where software must remain economically viable. The system must evolve along with the business without collapsing under its own complexity.

Most of the industry focuses almost entirely on Level 1, because Level 2 is much harder to see.

The Observability Problem

In many engineering disciplines, different designs can be compared directly.

Two airplane designs can be tested against each other. Two bridge designs can be analyzed under the same load conditions. Engineers can evaluate alternatives objectively.

Enterprise software is different.

Most systems are unique implementations of a specific business domain. A logistics system for one company will not be rebuilt several times with different architectures just to compare which approach works best.

Because of that, organizations rarely observe multiple competing implementations of the same domain.

There is no side-by-side comparison like:

System A — rich domain model
System B — procedural service architecture

running the same business processes for several years.

Instead there is only one system: the one that was built.

As a result, success is evaluated using the only clearly visible metric:

Does the application run?

If the answer is yes, the architecture is usually considered successful.

The Rise of the Software Factory

Over time, the industry optimized for what was easiest to measure: producing working applications quickly.

This led to the emergence of standardized software production lines.

Typical enterprise stacks often follow a very familiar structure:

controller
service
repository
database

Add REST APIs, containerization, messaging infrastructure, and often microservices, and a predictable pattern emerges.

Framework ecosystems reinforce this pattern. They provide conventions, templates, and project generators that make it easy to spin up new services quickly.

From an organizational perspective, this approach promises several advantages:

developers can move between projects easily
teams can scale rapidly
systems follow familiar patterns
onboarding new engineers becomes simpler

These promises are appealing, especially to organizations managing large engineering teams.

However, these advantages are rarely tested against alternative architectural approaches. Because most enterprise systems are built only once, there is no direct comparison showing whether a different design would actually have been more efficient or easier to evolve.

As a result, the perceived success of factory-style development often rests on a simple observation:

The application runs
Features are delivered

Without a comparable implementation built around a different architectural philosophy, it is difficult to see whether the chosen approach truly delivered its promised benefits.

The result is a development process that resembles a software factory: a standardized production line designed to produce working applications quickly.

Whether it produces the right kind of system for the domain is a different question entirely.

The Model T Problem

The logic behind this standardization is similar to the philosophy associated with Henry Ford and the Ford Model T.

The Model T revolutionized manufacturing through standardization. One of the famous ideas attributed to Ford was that customers could choose any color, as long as it was black.

This approach worked because the product itself was standardized.

Cars were produced for a broad market with relatively similar requirements.

Enterprise software is fundamentally different.

Each system represents a specific business domain:

logistics operations
insurance policies
trading platforms
healthcare workflows

These domains have very different requirements and behaviors.

In effect, each enterprise application needs a different type of vehicle.

Some domains resemble heavy trucks carrying complex transactional logic. Others behave more like high-performance machines, where performance and precision matter enormously. Some systems are small and lightweight.

Yet many development ecosystems attempt to solve all of them with the same architectural pattern — the equivalent of producing a Model T for every possible use case.

Why This Appears to Work

Despite the mismatch, the Model T architecture still appears successful.

After all, a Model T can still move forward. It can transport people and even carry small loads.

Similarly, standardized enterprise architectures can deliver features:

endpoints respond to requests
data is stored and retrieved
workflows execute

From the outside, the application works.

Because organizations rarely build the same system twice with different architectures, they never see a direct comparison. There is no competing design demonstrating that the system could have been far simpler or easier to evolve.

As long as the application runs and delivers features, the architecture appears to perform as expected.

The Hidden Cost of Factory Style Development

The real cost of factory-style architectures emerges gradually and usually in two dimensions: effort and functional quality.

Effort: Why development gets slower over time

In factory-style systems, implementing new functionality tends to require roughly the same effort every time.

Every feature follows the same pattern:

controller
service
repository
integration logic

Because the architecture is primarily procedural, the system rarely accumulates reusable domain behavior. Each feature often introduces new service logic rather than building upon existing concepts.

As the system grows, the situation frequently worsens:

similar logic appears in multiple services
developers must read many parts of the system to understand behavior
debugging requires tracing through multiple layers and integrations
knowledge transfer becomes difficult

The effort required to implement new functionality often remains constant or even increases over time.

Function-driven systems behave very differently.

When a system evolves around a coherent domain model, the model itself becomes a growing knowledge base of the business. Domain objects accumulate responsibilities and reusable behavior.

As the model matures:

new features often extend existing objects
behavior is reused rather than reimplemented
developers can understand the system by understanding the model

Knowledge transfer becomes easier because the model tells the story of the application.

Debugging is also simpler. When rules live in their responsible objects, it becomes immediately clear where behavior originates. Developers do not need to search across multiple services implementing slightly different versions of the same logic.

Over time, the effort required to add functionality tends to decrease, because the model provides increasing leverage.

Quality: One version of the truth

Factory-style architectures often distribute business rules across multiple services.

It is common to find logic that is similar but not identical in different places:

slightly different validation rules
small variations in calculations
edge cases handled in one service but not another

These inconsistencies are rarely intentional. They appear gradually as new features are implemented independently.

The result is a system with multiple interpretations of the same business rule.

Function-driven systems address this differently.

Each business rule belongs to the object responsible for that concept. The rule has one canonical implementation.

If a system contains an Order concept, the logic related to orders lives with the Order object. If there is pricing logic, it belongs to the pricing model.

This creates a single version of the truth.

Rules are not scattered across services or hidden inside orchestration layers. They are located where the business concept itself lives.

This greatly reduces contradictions and makes the system far easier to reason about.

The Engineering Principle

Enterprise systems should be function-driven rather than tool-driven.

Architecture should begin with understanding the domain:

the concepts involved
the relationships between them
the rules that must remain consistent

Only after that understanding emerges should tools and frameworks be introduced to support the system.

Tools are valuable when they solve real problems in the running application:

persistence
messaging
scaling
reliability

But they should not dictate the structure of the domain model.

Why Rich Domain Models Help

A function-driven system begins with the domain model, not with architectural patterns or infrastructure.

Instead of starting with decisions like:

microservices
event-driven architecture
CQRS
messaging platforms

development begins with understanding the domain itself.

The first goal is to model the core concepts and their responsibilities.

Typical objects might represent concepts such as:

Order
Customer
Shipment
Invoice

These objects contain the behavior that defines the business logic.

At this stage, the focus is entirely on implementing the core functionality of the application.

Infrastructure concerns are introduced only when they become necessary.

For example:

persistence is added when data must be stored
messaging appears when asynchronous coordination is required
scaling mechanisms appear when load actually demands them

In practice, many enterprise systems never reach the scale that requires complex distributed architectures.

For the majority of applications, a well-designed domain model within a cohesive system is entirely sufficient.

Only when real operational constraints appear should the architecture evolve technically.

This approach keeps the system aligned with the domain while avoiding premature technical complexity.

The result is software that grows organically around the business model, rather than being constrained by predefined architectural templates.

Closing Thought

TThe software industry has become extremely good at producing applications that run.

Frameworks, templates, and standardized stacks make it possible to build complex systems faster than ever before.

But enterprise software is not a short-term product. It is a long-lived system that must evolve together with the business.

Designing such systems requires something different from a software factory. It requires starting with the domain, building a coherent model, and letting the architecture grow from the problem instead of from the tools.

Otherwise we keep producing the same solution for every problem:

another black Model T.

The problem with that approach is not aesthetic. It is economic.

When the architecture does not match the domain, the mismatch shows up in three places:

more engineering effort to implement and understand functionality
higher long-term costs as development slows and operational complexity increases
more fragile systems where business rules are scattered and difficult to reason about

In other words, the wrong architectural vehicle does not merely look inelegant — it makes the system harder and more expensive to operate for the rest of its lifetime.

Long-lived enterprise software requires something better than a one-size-fits-all production line.

It requires architectures that are designed around the domain they serve.