Friday Fun: The Small Change That Was Not Small

Every experienced engineer has heard the same sentence at least once: "Could we just make a small change?" What follows is rarely small.

Friday afternoon meetings possess a particular atmosphere. Energy drops slightly. Laptops begin to close. Someone mentions the weekend. People want to unblock the last item before everyone signs off.

Then it happens.

A voice from the other side of the table asks, perfectly reasonably: “Could we just make a small change?”

The room nods. The request sounds harmless. A field on a screen. A small adjustment to a workflow. Perhaps one additional validation rule. Nothing dramatic.

Only one person in the room reacts differently. The engineer does not object. He does not sigh. He simply pauses for a moment. Not because the request sounds difficult, but because he has heard that sentence many times before.

Inside his head, a quiet process begins. Where does that field come from? Which service owns the data? Who consumes the response today? Does the database schema assume a different meaning? Which tests rely on the current behaviour? Is there a transformation layer involved? Is the mobile application caching the result? Is there a report somewhere that expects the previous value?

None of this appears on the meeting room whiteboard. To everyone else, the change still looks small. But in the engineer’s mind, a map starts to form.

The first connection appears. The new field comes from another service. That service does not store the value directly. It receives transformed data from a processing layer. The processing layer depends on a mapping table introduced three years earlier when the system supported a slightly different workflow.

The mapping feeds a reporting pipeline. The reporting pipeline generates a customer export. The export format assumes the current behaviour. Meanwhile, a mobile client caches the API response for performance reasons. And somewhere in the infrastructure, a terminal still runs an older client version that nobody has touched in years.

On the whiteboard, the drawing begins with a clean box. Then another. Then arrows. Then more arrows. Soon there are side notes. Then exceptions. Then question marks.

At some point the tidy diagram quietly turns into spaghetti. Not because the engineers lack competence, but because systems accumulate history.

The engineer remains calm. No panic. No drama. Just recognition. This is what experienced engineers do: they follow the signal through the system.

In many ways, it resembles archaeology. Layers appear. Decisions from the past surface again. Old assumptions reveal themselves the moment someone tries to change them.

By minute twelve, the phrase “small change” has already touched three services, two databases, a deployment pipeline, one forgotten cron job, and a script written by someone who left the company during the Boris Johnson era.

The room begins to laugh. Not because the situation feels absurd, but because it feels familiar.

At that moment, something important happens. People begin to understand that the engineer was never resisting the idea. He was tracing the consequences.

That difference matters. What looked like hesitation was actually system literacy. Mature engineering rarely means writing code quickly. It means understanding the network of relationships inside the system before touching it.

Stories like this often stay inside meeting rooms. But the same dynamic exists far beyond them. In the real world, complex systems do not live on whiteboards. They run banks, exchanges, airports and logistics networks.

When hidden coupling, fragile assumptions and rushed changes meet production environments, the consequences stop being amusing. A supposedly isolated modification can ripple through financial systems and expose data that should never appear on another customer’s screen. A contained deployment can travel through tightly coupled trading infrastructure and bring markets to a halt. A routine software update can quietly disable terminals across airports and leave thousands of travellers staring at blank check‑in screens.

The underlying pattern rarely changes. Small changes reveal the depth of the system.

This does not mean engineers should fear change. Quite the opposite. Change remains the essence of engineering work.

But experienced engineers understand something that every complex system eventually teaches: there is no such thing as a small change. There are only changes whose consequences have not yet been discovered.

Which explains why seasoned engineers pause when someone asks for one. Not to block progress, but to understand the system well enough to change it safely.

They reach for the whiteboard. They start drawing boxes and arrows. And somewhere in that expanding diagram lies the quiet story of how real systems evolve.

A story rarely dramatic, often messy, and always more interesting than the phrase that started it all: “Could we just make a small change?”