One-Line Fix, Ten Files Changed: What That Tells You About Your Software

You ask for something small. Change the word "order" to "booking" across the customer screens. Add a field to a form. Make the invoice total round to two decimal places instead of four. It sounds like a five-minute job. The quote comes back for two days.

Either the developer is padding the bill, or something in the code is making a tiny change spread much further than it should. Usually it's the second one. There's a name for it: change coupling.

What change coupling actually is

Change coupling is simply how many files, screens or systems have to be edited together whenever you change one thing. Low coupling means a small request stays small: you change the logic in one place, and everything that depends on it picks it up automatically. High coupling means the same piece of business logic has been written out, or copied, in several different places, so a single change has to be made in all of them, correctly, every time.

You don't need to read code to notice it. You can see it in how a developer reacts to your request. If a word change touches ten files, something is duplicated that shouldn't be. If adding a field means editing the database, the form, the API, the PDF export and the reporting screen separately, with no single place that defines "what a booking looks like", that's change coupling.

Why it builds up

It's rarely laziness. It's usually a side effect of how software grows under pressure:

• A rule gets written once for a feature, then copied for a second feature because copying was faster than refactoring at the time.
• The front end and back end both calculate the same number (a discount, a tax rate, a deadline) independently, because nobody built a shared place for that calculation to live.
• Different developers, over different years, solved the same problem in slightly different ways, and nobody went back to merge them.
• A quick AI-generated change solved today's ticket by copying an existing pattern rather than extending it, because that was the fastest route to something that compiled.

None of these are unreasonable decisions in isolation. The cost shows up later, when you ask for a change that should be routine.

How it shows up as cost to you

This is the part that actually matters if you're paying for the work rather than writing it. Change coupling doesn't make itself known until you ask for a change, and by then you're already committed to the quote. A few patterns I see regularly:

• Quotes that don't match the request. You ask for something that sounds like a one-line fix and get a quote that reads like a feature build, because the fix has to be made in several places to actually take effect everywhere.
• Bugs that appear somewhere unrelated. A fix to the checkout page breaks something on the admin dashboard, because both were calculating the same total independently and only one got updated.
• Every new feature gets slower to add. Each one adds another place the old logic has to be copied into, so the problem compounds rather than staying flat.
• Nobody wants to touch the code. If every change risks breaking three other things, a developer will naturally slow down and add more caution, more testing, more hedging. That caution is reasonable, but you're the one paying for it.

How to check for it before you commit

You don't need to be technical to ask the right question. Before you commission new work, or take on a developer for an existing system, ask something concrete: "If I wanted to change how a discount is calculated, how many places would that touch?" A developer who knows the codebase well should be able to answer that in a sentence or two. If the answer is vague, or involves a long pause, that's worth noting.

If you're taking on an inherited system, this is one of the first things worth checking, alongside whether anyone can explain how it was built at all. I've written before about what to do when you inherit a system nobody can explain, and change coupling is usually part of that picture. A system with high coupling and no documentation is the combination that costs the most to work on safely.

What lower coupling actually looks like

The fix isn't to rewrite everything at once. It's to make sure the things that are genuinely one rule stay as one rule, with everything else reading from it rather than repeating it. A discount calculation lives in one function, called from checkout, from reports, and from the admin screen. A customer's full name is assembled in one place, not re-concatenated in every template. When that's true, a change request that sounds small actually stays small. Getting there usually means noticing where duplication has crept in and consolidating it gradually, as part of normal work, rather than stopping everything for a rewrite. That's a judgement call on almost every project I take on, and it's one reason I'd rather look at the actual code before quoting a change than estimate from a description alone. It's the difference between a quote that reflects the request and one that reflects what the code is actually going to make you pay for.