A System That Runs Isn't Necessarily Ready to Grow

💡 A system that works isn't necessarily a system that's ready to keep growing.

This is something I've felt more and more strongly over the past few years.

After returning to Taiwan from working on ERP systems in Xiamen roughly seven or eight years ago, I went on to work on quite a few different kinds of projects.

Many weren't particularly large systems. They were more like this:

A new requirement comes in, so we build the feature. Another requirement arrives, so we add something else on top.

Keep doing that long enough and you end up in a very familiar situation:

All the features are there, and the system runs, but everything is scattered everywhere.

Folders, shared methods, business logic, database operations, logging, caching...

Is that necessarily "wrong"?

From a user's perspective, honestly, perhaps not.

Users don't care how you implement logs, where the cache lives, or how you access the database. They care about one thing:

"Does the feature work?"

The problems usually begin to show up when the system starts growing.

🧩 Over time, I've become quite insistent about one thing:

At the very least, separate the "system core" from the "business features".

Later, if the system is a product with a standard version, custom versions, or extensions for different customers, that's when I'd consider a third layer: SpecFeature.

Why bother with all of that?

Because some capabilities shouldn't be implemented separately in every Feature.

For example:

Logging, caching, and database access.

These are capabilities used across the system, rather than logic belonging to one particular business domain.

Without that boundary, two things happen very easily.

1️⃣ We keep writing the same things again.

We implement something for Feature A today, and do it all over again for Feature B tomorrow.

Eventually we either copy and paste or everyone writes their own version.

2️⃣ Those versions start drifting apart.

A includes logging. B forgets it. C uses one caching approach. D uses another.

At first these differences look tiny.

But when something actually breaks and we need to change it, we enter a very familiar situation:

"Okay, I think I know where the problem is."

Then we open the code.

"...How on earth am I supposed to change this whole mess? ˊ_>ˋ"

What seemed like a one-hour fix turns into tracing every caller, finding copies, and checking who modified which version.

An entire afternoon disappears.

🔍 On the other hand, when system boundaries are clear from the beginning, at least we can narrow the problem down:

"Is this a shared system capability that's failing?"

Or:

"Is this business logic specific to a particular Domain?"

Just being able to reduce the scope of investigation makes a huge difference.

🤖 And with AI now in the picture, this matters even more to me.

AI is genuinely convenient. Give it a whole Repository and it can read through a huge amount of code very quickly.

But if the project is scattered to begin with, with the same responsibility spread across five or six places and implemented differently in each, AI is still looking at that same scattered mess.

And the result may be exactly what I described above:

A remembers a detail, B forgets it, and C takes a completely different approach.

AI can help us read things much faster. But just because we're using AI doesn't mean a system without clear boundaries will magically develop beautifully defined ones.

If anything, AI might simply make the existing mess grow faster.

I've felt this quite strongly when taking over smaller projects with a lot of legacy technical debt.

So these days, when I'm planning a new system that may need to keep growing, I try to protect at least two layers:

SysCore / Feature

And when a product needs a standard foundation with extensions for different requirements, I consider:

SpecFeature

👉 In the next post, I'll talk about how I personally distinguish SysCore, Feature, and SpecFeature.

Once you get deeper into these boundaries, it's not just about saying:

"Hey, my folders are better organized."

It's more like building a Framework that gives the entire project a shared structure.

💬 If your project has reached the point where:

"We keep adding features, but now we don't know where anything belongs,"

I'd love to hear how your team separates the system core from business features.

If you're working through something similar, feel free to comment or send me a message.