Good code is a place for change

Ask what makes code good and most answers reach for the same words: clean, elegant, readable, well-tested, modern. None of them is wrong, and none of them is the thing that matters most. A codebase can be all five and still be a place where every new feature is a fight. It can be none of them and still be a place where change is cheap.

Good code is code where the next change has an obvious place to go.

That is the whole definition, and it is worth slowing down on, because it moves the question from how the code looks to what the code does for the person who has to change it next — which, on any system that lives past its first quarter, is the only question that pays.

A feature is never one thing

The reason this matters shows up the moment a product grows past its first screen. You add one small feature — say, a discount for annual plans. It looks like one thing. Then it needs a setting somewhere, a rule about who qualifies, a line on the invoice, an email confirming it, an admin control to grant exceptions, a database field to record it, and an error case for when it collides with an existing coupon. The feature was never one thing. It is seven, and each part needs somewhere to live.

If each kind of part has an obvious home — one place identity is decided, one place the discount rule lives, one place email is sent and recorded — then adding the next discount-shaped feature is mostly a matter of putting each part where its kind already goes. If those homes are unclear, each part still gets placed, just not on purpose: the rule ends up copied into the frontend, the invoice template, and a database script; the email logic sits half in a controller and half in a helper nobody named; and the truth about who actually gets the discount drifts into one developer's memory.

The feature works either way. That is the trap. Working is not the property that matters. The property that matters is whether the next change to it knows where to go.

What it looks like in the code

Plainly: a business rule should live in one place, so the next person changes it once instead of hunting three copies that have quietly drifted apart.

Technically, that is what a layer boundary buys you. The controller owns the HTTP shape. The business service owns the rule. The repository owns persistence. When the discount rule changes, the edit lands in the business service and nowhere else — not because a style guide demanded it, but because every other layer was built so it does not need to know. A developer asking "where is the discount decided" gets one answer, and the answer points at one file. The change is small, local, and safe to make — which is the only kind of change a growing company can afford to keep making.

This is also why a system can be ugly and still be a good place for change, and elegant and still be a terrible one. A blunt, plainly written service with one clear responsibility is a better home for the next change than a beautiful abstraction that three unrelated features reach into. Elegance describes how the code reads today. Quality of change describes what happens to it next. They are not the same axis, and when they conflict, the second one is the one that costs you money.

The honest limit

None of this means a good system is finished, or pretty, or free of compromise. Every real codebase carries places where the home for a rule is still unclear, or where two features share a seam they should not. The difference is not the absence of those places — it is whether the system makes them visible. Whether you can point at the spot where ownership is unclear and name it, instead of meeting it a year later as a bug nobody can explain.

That honesty is the standard I hold my own systems to. Each value I work by is paired with the exact place in a live, running system where it can be checked — including where that system is currently falling short. They are written out, with their anchors, on the values page.

Why this is the centre of owning a system

When I take ownership of a system, this is the standard the work moves toward. Not "make it elegant." Make it a place where the next valuable change is cheaper, safer, and better-grounded than the last — so the second feature reuses what the first one established, and the tenth still has somewhere to land.

That is what ongoing ownership of a system is for. The code getting cleaner along the way is a side effect. The code becoming a place where change has somewhere to go is the job.