Solving one problem without creating the next one

As developers we sometimes want to solve a problem too quickly.

• An exception appears — we fix it.
• Performance is poor — we add a cache.
• The services are too tightly coupled — we split off a new one.
• There are too many database calls — we write a different query.

The problem is solved. Then another problem appears.

A fix is not always a solution

I have seen this several times on real projects. A change that removes one problem can create new behaviour somewhere else.

Caching a value can take load off the database. But now you have to decide when that value is refreshed.

Splitting off a service can make deployment easier. But now a network problem is your problem too.

Adding a validation can stop bad data. But now the same rule has to be applied at every other entry point.

In other words, a technical decision has a price of its own.

I ask “why” first now

Before making a change, I try to understand the problem as far as I can.

• Why is this happening?
• Which layer is the problem in?
• What else could this change affect?
• Is there a simpler solution?

And the one that matters most: am I actually solving the problem, or only hiding the symptom?

That question stops a lot of code from being written.

The simple solution is usually the better one

For me, good backend code is not the code with the most abstraction in it.

If the problem can be solved clearly inside one service, there is no point adding a layer purely so the architecture looks more “professional”.

If a database constraint solves the problem, there is no obligation to keep that rule in Java code alone.

And if two modules change together, pulling them apart artificially is not automatically the right call either.

More and more, I find engineering is less about knowing what to add than about knowing what not to add.