✨ How I Measured the Real Complexity of a Logic Layer

– Using AI and Python to analyze a mid-size production system

Haru

3 min read

·

Mar 5, 2026

--

Listen

Share

During a system migration assessment, I encountered a very practical question:

How much of the Logic layer could actually be migrated directly?

There was no design documentation.

No unified specification.

Only the legacy code itself.

If the migration risk were judged purely by experience, the conclusion would likely fall into one of two extremes:

• Overly conservative.
• - Or overly optimistic

So I decided to approach the problem differently.

Instead of estimating the complexity, I tried to measure the structure.

Press enter or click to view image in full size

✨ Why Structural Quantification Matters

In migration projects, the most misleading metric is often lines of code.

What really matters is not the total LOC, but the distribution of logic structures.

Different structures have completely different migration costs.

For example:

• Pure business logic.
• - Search condition construction.
• - Standard CRUD operations.
• - Complex update operations

Each category behaves very differently during migration.

If we do not know the structural composition of the Logic layer, it becomes almost impossible to estimate the actual migration effort.

– -

✨ Method: Scanning the Logic Layer

To avoid manual inspection, I wrote a small Python script to automatically scan the Logic layer.

The script performs several tasks:

• Read all Logic layer files.
• - Extract effective lines inside methods.
• - Identify structural patterns.
• - Aggregate statistics by category

The goal was not perfect accuracy.

Instead, the objective was to produce a structural distribution map of the system.

– -

✨ Structural Categories

During the analysis, Logic layer methods were roughly classified into four types.

1️⃣ Pure Logic Processing

Examples include:

• Data transformation.
• - Conditional branching.
• - Internal calculations.

These structures typically have the lowest migration risk.

– -

2️⃣ Search Processing

Examples include:

• Query condition construction.
• - Dynamic SQL building.
• - Result filtering.

These structures usually depend heavily on data access patterns.

– -

3️⃣ Standard CRUD

Examples include:

• insert.
• - update.
• - delete.
• - simple select.

If the data access layer remains stable, these methods can often be migrated almost directly.

– -

4️⃣ Complex Updates

Examples include:

• multi-table updates.
• - conditional update flows.
• - transaction-heavy operations.

This category often represents the highest migration risk.

– -

✨ Structural Distribution

After scanning the Logic layer of a mid-size system, the effective code size was approximately 10k LOC.

The distribution revealed a very interesting pattern.

Logic Layer Structure (~10000 LOC)

Pure Logic Processing
████████████████████████████ 40%

Complex Updates
████████████████████ 30%

Search Processing
████████████████ 25%

Standard CRUD
█ 1%

Figure 1. Structural distribution of the Logic layer.

Most business logic in real systems is not CRUD.

It is conditional processing and complex updates.

– -

✨ Intuition vs Reality

Before running the analysis, my initial estimate looked very different.

My intuition suggested something closer to:

• Pure logic: ~25%
• - Search processing: ~30%
• - CRUD: ~25%
• - Complex updates: ~20%

But the actual structure told another story.

The biggest discrepancy was CRUD.

In practice, CRUD logic was almost nonexistent in the Logic layer.

Instead, most code consisted of:

• conditional logic.
• - data transformation.
• - complex update operations

This also explains why many migration projects become significantly harder than originally expected.

– -

✨ Collaboration Between Engineers and AI

Interestingly, I do not normally write Python.

The script structure itself was generated with the help of AI.

My role was to:

• define classification rules.
• - design the structural categories.
• - validate the results

The AI assisted by:

• generating the script structure.
• - fixing syntax errors.
• - refining the implementation

This created a new form of collaboration:

Humans define the structure of the problem,

AI executes the mechanical analysis.

– -

✨ Engineering Implications

The most important outcome of this exercise was not the script itself.

It was the shift in thinking.

From:

judging complexity by intuition

to:

understanding complexity through data.

In systems without reliable documentation, the behavior of the code itself becomes the specification.

By analyzing structure, we can:

• observe system composition.
• - quantify migration complexity.
• - evaluate risk more objectively

– -

✨ Conclusion

Many engineering problems do not require more sophisticated tools.

They only require one thing:

turning vague questions into measurable structures.

Once the structure becomes visible,

the decision process becomes much clear