DEV Community: Stelios

Surface Tension of Software: why systems hold together

Stelios — Sun, 07 Dec 2025 14:00:56 +0000

If you press your finger against water, it pushes back. That invisible resistance, surface tension, keeps the liquid whole even when disturbed.

Good software has something like it. Some systems hold together when you change them; others leak at the slightest touch. The difference lies in integrity — the way a system manages its side effects without losing its shape.

I've seen codebases that felt strangely calm, where every possible state meant something real and nothing arbitrary could slip in. Others allowed nonsense to exist, and from there, entropy spread quietly like cracks beneath paint.

Type systems, invariants, and boundaries exist to make meaning explicit. They define where things start and stop — what’s allowed, and what isn’t. Without that structure, logic turns soft; assumptions spread, and the system eventually folds under its own ambiguity.

Systems stay whole when their structure insists on coherence: clear boundaries, honest interfaces, consistent language.
Each adds its own gravity, and together they make a world that holds. Stability isn’t declared; it emerges from the sum of small, consistent forces.

Constraint-driven design makes that gravity visible. In software, these laws have names: purity, immutability, idempotence, transparency, composability. They’re the physics that keep a system in orbit.

Pure functions return the same output for the same input, with no hidden effects. Immutable data can't be changed after creation, only transformed. Idempotent operations produce the same result no matter how many times you apply them. These aren't academic exercises — they're physics that prevent the impossible.

But let one careless change skip a step and the world tears.

Consider a UI that fetches user data. Without tension, it leaks:

struct UserProfile {
    loading: bool,
    error: Option<String>,
    data: Option<User>,
}

What does it mean when loading is false, error is Some, and data is also Some? The type allows nonsense. You write defensive checks everywhere. Every render must guess which combination is real.

Now give it shape:

enum UserProfile {
    Loading,
    Failed(String),
    Loaded(User),
}

The impossible states vanish. You can't be loading and failed. Pattern matching forces you to handle every valid case, and only those. The type system becomes the membrane — it holds the shape.

In well-shaped systems, nonsense simply cannot exist because the universe of the program doesn't contain it. You don't defend against the impossible. You design a world where the impossible has no syntax.

When those laws are clear, surface tension appears on its own — you feel it when refactors stop rippling outward, when a change bends without breaking, when boundaries push back just enough to preserve meaning.

Good patterns and abstractions behave like membranes. They don't restrain motion; they guide it. They contain side effects the way water's surface holds its ripples — movement without spillage, energy without collapse. Parsing, typing, composition: these are the laws of motion that let a system stay whole when disturbed.

There's an old engineering instinct that says, "We'll handle it later if it happens." But in coherent systems, it simply can't happen. You can only move through valid states, and that constraint is what makes motion possible at all.

But tension has its limits. Too much and water hardens into ice — flawless, unmoving, lifeless. Software can freeze the same way, becoming so rigid it forgets to flow. Balance lives somewhere between order and change, between holding on and letting go.

The best systems live there, in that delicate balance where structure meets freedom. And perhaps that's where the worlds of hackers and painters quietly meet, each shaping their medium until form and motion become one.

That precise balance is the true art of code.

Further reading:

Rich Hickey’s Simple Made Easy — a classic talk on why
simplicity comes from separation, not convenience.

Systems As Mirrors

Stelios — Sun, 12 Oct 2025 06:14:34 +0000

There’s something quietly unsettling about Conway’s Law. Most people who’ve worked in software long enough can sense its truth. What unsettles is what it reveals when you sit with it.

The law definition, in its original form, is:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

At first, it seems structural. Org charts become system diagrams. Split your teams by department, and the system splits the same way. But over time, the reflection deepens. The system doesn’t only mirror who talks to whom — it starts echoing what’s understood, and what’s avoided.

The most confusing systems I’ve seen don’t reflect complexity. They reflect ambiguity.

You see it in familiar places. One service checks a user’s admin flag. Another checks something else entirely. A third overrides both. A field like “approved” means one thing to scoring, another to compliance, and something looser to product. The code bends around uncertainty. But what it adapts to isn’t complexity — it’s a missing decision.

This gets worse when teams try to support everything. A lending flow starts with a clean path. Then you add freelancers, students, returning users. You don’t create new flows. You add flags: hasPayslip, isStudent, incomeSource. Logic branches. Models fork. Scenarios pile up.

Each rule makes sense in isolation. But together, they blur the center. “ApplicationApproved” starts meaning different things depending on the path taken. Eventually, no one can say what it means — only how it behaves under certain conditions.

The system still works. But its meaning doesn’t.

This is where outcome-driven modeling helps. Jobs To Be Done is one approach. It shifts the focus from who the user is to what they’re trying to accomplish. It asks what outcome they’re hiring the system to deliver — and what tradeoffs they’re willing to make.

A persona tells you the user is a freelancer who prefers mobile and has irregular income. The job tells you: access a short-term loan using recent invoices. Suddenly, the model sharpens. Income is about pattern, not payslips. Risk is about volatility. Rejection isn’t the fallback — manual review is.

When you model from outcome, the system knows what it's trying to do.

This is also where domain boundaries matter. Domain-Driven Design introduces the idea of bounded contexts: each part of the system defines its own meaning. Duplication isn’t always a mistake — it’s often how clarity is preserved. Reuse works best when meaning aligns.

Take the classic User model. In KYC, it means identity: documents, name, status. In Scoring, it means applicant: income, employment, credit history. In Auth, it means account: credentials, sessions, MFA. Reusing the ID is fine. Reusing the model leads to something brittle: dozens of nullable fields, conflicting assumptions, tangled dependencies.

Some say duplication is always bad. But that’s a narrow view. It depends on what’s being repeated. Echoing confusion spreads it. But repeating meaning reinforces clarity. Duplication isn’t the enemy — imprecision is.

Once each model speaks a single truth, everything downstream improves. The backend is easier to debug. The frontend becomes more predictable. Changes get safer. Teams stop negotiating the meaning of basic terms and start delivering again.

And that brings us back to the mirror.

Conway’s Law tells us systems mirror their makers. But reflections go further than structure. They echo our indecision, our shortcuts, the choices we didn’t make.

So the real question is:

If every system is a mirror — what part of ourselves are we willing to see?

Too Many Chefs, One Kitchen

Stelios — Sun, 08 Jun 2025 07:45:03 +0000

Most teams don’t start with architecture problems. They start by building. Fast. A small product, a tight team, a system that does just enough. And for a while, that’s the right choice. You’re shipping. You’re learning. You’re moving.

But at some point, usually when the business starts to grow, something shifts. Releases become slower. Teams start stepping on each other. And what once felt nimble now feels stuck.

Why?

The instinctive answer is technical debt — maybe the system just needs refactoring. Or maybe it’s a process problem. But often, the real issue is more structural.

Your architecture no longer matches your organization’s needs.

A common sign of this mismatch is deployment friction. One team wants to ship a small feature. But they have to wait. Wait for another team to finish testing. Wait for someone else’s changes to stabilize. Wait because even a tiny change means releasing everything.

The system works — technically. But it’s like sharing one kitchen with five different chefs.

One team’s baking. Another’s cleaning fish. Someone else just spilled oil on the floor.

You can coordinate. You can take turns. But you can’t move freely. And eventually, the kitchen becomes the bottleneck.

This is what monoliths often feel like: centralized, coupled, and fragile under pressure.

Microservices don’t solve everything, but they restructure the problem. By giving each team their own “station,” they reduce the coordination tax. Teams can deploy independently. They can fail independently. They can learn faster, without always waiting for the rest of the kitchen to finish cooking.

That doesn’t mean microservices are always better. Just that at a certain scale — of product, of people, of change — they become a way to align architecture with the shape of the organization.

What follows is a simple example — not to show how to “do microservices,” but to make clear what kind of friction they solve, and why it starts to matter more as teams grow. Think of it as a zoom-in on what happens when structure starts slowing teams down — not because of failure, but because of how things are bundled.

⸻

Imagine a SaaS platform offering payment processing and loyalty features for small businesses. It’s been growing steadily, and the codebase — a monolith — has carried the company through its early traction. Releases are coordinated, large, and slow, but manageable.

Then a new opportunity arises.

The product team identifies a small pricing optimization — tweaking loyalty point accrual rules to encourage repeat purchases. It only affects existing users. Forecast models suggest it could increase annual revenue by 2%. It’s a focused change, with minimal risk, and the team wants to run a fast A/B test to validate it.

But it can’t ship.

It’s bundled into the same release as a compliance update — one that applies exclusively to new customer onboarding and affects shared reporting logic. The loyalty change, meanwhile, is for existing users. The two have nothing to do with each other, but because they live in the same monolith, they move together. You just want to add a bit of seasoning and send the plate out. But the kitchen won’t let anything leave until the whole menu is rewritten.

So the loyalty experiment waits. And each day of delay costs more than just projected revenue — it delays validation. No test runs. No feedback arrives. The team can’t iterate. Momentum slows. The problem isn’t the work. It’s the structure that forces unrelated changes to move together.

Microservices would let the loyalty team ship on their own terms. They could release early, run the test, learn what works, and improve the feature before the week’s over. And perhaps more importantly — they’d own the outcome from end to end.

Architecture changes behavior.

When teams can move without waiting, they start testing more, listening sooner, and improving faster. Not because of a mandate — but because the system allows it.

But that freedom doesn’t come for free.

⸻

It’s easy to see microservices as the fix: split the kitchen, give each team their own space, and let them move fast. And when done right, it works.

But it also comes with a new kind of burden.

Every kitchen now needs its own tools, its own cleanup, its own supply of ingredients. And to make something great, those ingredients need to be fresh, high-quality, and well-managed — and that adds not just effort, but real operational cost.

Microservices give you autonomy — but only if you're mature enough to handle it.

That means good testing. Clear ownership. Reliable observability. Solid deployment pipelines. If any of those fall short, the service breaks — or worse, breaks others silently.

Monoliths concentrate complexity in one place. Microservices distribute it.

Which means you don’t reduce complexity — you just move it.

If the teams aren’t ready — if the ingredients aren’t right — you won’t get autonomy. You’ll get inconsistency. Drift. And a lot of mess to clean up.

And so the question becomes: when do you make the shift?

You don’t need five kitchens on day one.

A single shared space works just fine — until it doesn’t.

Microservices aren’t a milestone to reach.

They’re a response to something felt: friction, delays, coordination overhead that’s no longer manageable. If your teams are shipping smoothly, if ownership is clear, if feedback loops are tight — stay where you are.

But when the line to cook is longer than the cooking itself — when teams spend more time waiting than building — it’s worth asking whether the kitchen still fits.

Structure should serve the pace and shape of your product.
If it starts slowing you down, it’s time to reshape it.

The best teams aren’t just fast.

They’re intentional about the systems they build around them — not just in code, but in how they move.

Architecture is just one part of that system. But it’s powerful.

Because when it’s right, it doesn’t just unblock delivery.

It unlocks behavior.