Separation of Concerns

A larger computer program consists of many parts that work together. Separation of Concerns describes exactly that: the principle requires that each part of the program is responsible for exactly one clearly defined task. One part fetches data from memory, another processes it, a third displays the result on screen. These parts know as little about each other as possible and exchange only what is strictly necessary. The term goes back to the Dutch computer scientist Edsger Dijkstra, who described it in 1974.

Why mixed-up code eventually becomes unaffordable

Software is rarely written once and never touched again. It is extended, fixed, and adapted for years. When everything is mixed together with everything else, every small change has unpredictable consequences in completely different places. Developers call this “spaghetti code”: you pull on one noodle and half the plate moves with it.

Separated responsibilities limit the damage. If only one building block is responsible for the display, you can change the design without touching the calculation logic. Debugging also becomes easier. If the app shows the wrong price, you only need to check a few clearly named spots.

On top of that comes division of labor. In a team of twenty people, several people can work simultaneously without constantly getting in each other’s way. Everyone is responsible for different building blocks. Without a clean separation, teams block each other, and development gets slower and slower as size grows.

Interfaces as boundaries between the building blocks

In practice, boundaries are drawn using so-called interfaces. An interface is an agreement about which requests a building block answers and what response it delivers. How it does this internally remains its own secret. You can later rewrite the building block completely, as long as the agreement stays the same.

A common pattern is division into layers. The data layer talks to the database, the logic layer contains the actual rules, the interface layer takes care of what the user sees. Each layer talks only to the one directly below it. A similar idea underlies microservices, that is, many small programs each covering one sub-area.

A common misconception is that more separation is always better. Every boundary costs something: more files, more agreements, and with microservices also network traffic between the parts. Anyone who breaks a tiny program into fifty building blocks makes it more confusing rather than clearer. Separation makes sense where tasks really do change independently of one another.

From school projects to AI systems

Anyone who programs encounters the principle early on. Even a small website separates content, presentation, and behavior into different files: HTML for the text, CSS for the appearance, JavaScript for the interaction. That is exactly Separation of Concerns on a small scale. You can completely replace the appearance without touching the content.

In AI products, the separation is particularly visible. A chatbot usually consists of a language model that generates text, a search component that fetches facts from documents, and a filter layer that blocks problematic answers. These parts are developed separately and swapped out separately. A provider can replace the language model with a newer one without rebuilding the search.

The topic also comes up indirectly in business news. When a company reports that it has modernized its old software or broken it down into microservices, it is almost always about this principle. Such overhauls often take years and cost a lot of money. The hoped-for benefit is that new features can then be built in weeks instead of months.