Changing a Working System Is Not the Same as Writing in a Blank File

When you build a new system, everything feels easier.

The file is empty. You define the rules. Nobody has gotten used to the system yet.

But in real projects, things usually don’t work that way.

Most changes are made on top of a system that is already running. Someone uses it every day. Another service depends on it. There is already years of data in the database.

So when I get a change request, one of the first things I ask myself is: is this something completely new, or does it touch a process that is already working?

A “small change” isn’t always small

A ticket might say:

• “We just need to add a field.”
• “Let’s just change the status.”
• “Let’s make this rule a little less strict.”

On the screen, these can look like very small changes.

But before changing the code, other questions come up:

• If this field didn’t exist before, what happens to the old data?
• What processes will be affected when the status changes?
• If we make the rule less strict, which operations that previously failed will now pass?
• Does this change affect other services, reports, or payment processes?
• Will the existing data and processes still be correct after the change?

Writing the code without thinking about these things is easy.

The difficult part is making sure that the change doesn’t silently create a problem somewhere else in the system.

I first think about what shouldn’t break

Before starting a new feature, I try to understand the existing process.

• How does it work now?
• Who uses it?
• Which code and processes depend on it?
• What can be changed, and what should be left untouched?
• Most importantly — will the existing data and processes still work correctly after the change?

You notice this especially when working with banking systems.

Breaking an existing process there isn’t just about creating a “regression”. You are changing a process that people rely on and trust.

But this isn’t limited to banking systems.

If someone uses the same system every day, a change you make also affects their daily work.

Sometimes you make their job easier without even realizing it.

Other times, a small-looking change creates a problem somewhere else.

What is a good change to me?

For me, a good change isn’t simply one that fulfills the new requirement.

It should solve the new requirement while also protecting the existing system.

For example:

• The new behavior should be clear.
• The old behavior shouldn’t be broken accidentally.
• When an error occurs, the system shouldn’t silently create incorrect data.
• The reason behind the change should be understandable to a developer who reads the code in the future.

Writing code is, of course, important.

But adding code to a working system is different from writing new code in an empty file.

There are already users, data, other services, and established business rules involved.

So for me, the process is:

• First, understand the existing process.
• Then, identify what the change could affect.
• Only then, write the code.

I think this is one of the important parts of software engineering: when adding something new, don’t accidentally break what is already working.