A hill to die on: there are no tiny changes

There’s no such thing as a small change

“Can we just move that button?”

“It’s just a quick fix."

“Tiny change, shouldn’t take long."

If I had a euro for every time I’ve heard that, I’d have long since retired from software, though probably not from cleaning up after so-called small changes. Let me say this loud and clear for the people in the back:

There is no such thing as a small change in software.

Every tweak, no matter how innocent it looks, sets off a chain of technical, architectural, and organizational consequences. Some are immediate; others quietly sit in the shadows until they break something important.

The myth of the harmless tweak

On the surface, it all seems trivial. Move a button. Rename a label. Add a checkbox. But under the hood, things are rarely that simple. Changing a layout might mean updating spacing logic, adjusting responsive behavior, and validating across multiple device types. A renamed label could trigger updates to automated tests, training documentation, screenshots, and localization files. Even a single UI element can ripple across the stack, touching everything from accessibility validation to release notes.

The development time for the change itself might be ten minutes. But doing it properly means ensuring nothing else breaks, verifying it behaves correctly in edge cases, and navigating governance processes. That can easily consume an entire day. Multiply that by the number of “quick wins” in a backlog, and you start to see the cost of this thinking.

When layout changes break real things

Changing a layout can, and often does, break things you didn’t intend to touch. That internal report used once a quarter? Gone, because the JavaScript function that rendered it was tied to a layout element that no longer exists. And oh I know! Ideally, a report-generating function shouldn’t be tightly coupled to a specific layout element. In a well-architected system, UI layout and business logic are clearly separated, with appropriate abstraction layers and clean interfaces. Unfortunately, lots of projects are not in that ideal state - and they suffer from just ship it mindset badly, where separation of concerns and encapsulation are treated as a nice to have, not a standard of how we develop software. But what about the screen reader that used to announce the “Submit” button? Now silent, because your oh-so-tiny change reordered the tab focus and wiped out the ARIA labels. The automated tests that ran fine last week? All failed last night, because your cleaned-up CSS classes broke the selectors used in the test scripts.

These aren’t hypotheticals. They’re the kind of things that creep in precisely because the original feature was rarely used, or only by specific teams like finance, legal, or compliance. It doesn’t matter that no one noticed during testing. They’ll notice when they actually need it. And by then, you’re already halfway through the next “minor” change.

Small surface, big impact

One of the most dangerous misconceptions in software is the assumption that something that looks small must be easy. It’s not.

Simplicity in appearance hides the complexity of interaction.

A design tweak that shifts the position of a component might sound like a harmless adjustment, but it could require revisiting layout logic, accessibility compliance, interaction flows, and translation strings, just to name a few. UI changes are rarely just UI. They’re system changes that happen to start with pixels.

What makes it worse is that developers often know this, but hesitate to say it out loud. Saying “this will take a day” makes you look like a blocker. So you nod, write the ticket, and let the cost show up later in the form of missed deadlines, brittle tests, or unhappy users. Everyone keeps the illusion alive because it’s easier in the moment.

Short-term relaxation means long-term tension, short term tension warrants long term relaxation.

The business cost of tiny lies

These illusions are expensive. You won’t see the impact of “just small changes” on a dashboard. It’s spread out: an hour lost here in testing, another in debugging, another rewriting documentation. But the cost is real. The more time teams spend chasing cosmetic requests, the less time they spend on real improvements. Productivity drops. Morale takes a hit. And quality quietly suffers. Meanwhile, the team that asked for the change? They’ve already moved on. The next request is in, and it starts with the same words: “Could we just…”

But what about typos?

This is where someone always chimes in: “Surely a typo fix is small?” Sometimes, yes. If it’s a plain text correction in a UI, it’s usually straightforward, just don’t forget to update the translation strings. But once you move beyond that, even typos can carry weight.

Fixing a typo in an error message, for example, can trigger a full localization workflow across ten languages. A label change might require updating automated tests, screenshots, and training documentation. A spelling mistake in a configuration file might not be a spelling mistake at all—it might be the one character that causes a parsing error and crashes the deployment.

Even a harmless code comment goes through version control, review, and deployment. It competes for attention with real fixes. So yes, some typos are genuinely tiny. But others are the software equivalent of stepping on a rake. And you usually don’t know which it is until your face hits the handle.

Treat change like the risk it is

If you want to move fast and deliver value, that’s great. But the path to speed isn’t paved with unexamined changes. It’s paved with clear priorities, contextual trade-offs, and honest conversations. Stop pretending that changes are small just because they’re visual. Evaluate changes by their impact, not their appearance. Bundle related work so teams aren’t testing blind. And for the love of software 💖, build a culture where asking “Why?” is seen as diligence, not defiance.

Final thought

Every change is a choice. Every “just one more thing” is a debt someone else pays. So the next time someone says, “Can we just…”, pause and ask: Do they understand what they’re asking for, or just what it looks like?