What Is Technical Debt?

Technical debt is the future cost you incur when you choose a faster or easier solution now instead of a better long-term one.

The term was popularized by Ward Cunningham.

Think of it like financial debt:

You borrow time now (ship faster)
You pay interest later (harder changes, more bugs, slower velocity)

Not all technical debt is bad. Sometimes it’s a strategic decision.

Types of Technical Debt

Intentional (Strategic)

You knowingly cut corners to:

Hit a deadline
Validate a feature
Test market demand

This is acceptable — if tracked and repaid.

Unintentional (Accidental)

Poor design decisions
Lack of experience
No architecture thinking
Rushed hacks that became permanent

This is dangerous because it grows silently.

Bit Rot / Entropy

Dependencies outdated
Tests flaky
Architecture no longer fits new features
Code becomes harder to understand over time

Even good systems accumulate this.

How Technical Debt Hurts a Backend Java System

In backend Java (especially Spring apps), debt often shows as:

Huge service classes
Tight coupling between layers
Massive @Transactional methods
Anemic domain models
Duplicate validation logic
Hard-to-test business logic
Slow build times
Fear of changing core modules

Symptoms:

Each feature takes longer than the previous one
Bug rate increases
Onboarding new devs is slow
Refactoring feels risky

That’s interest compounding.

How to Manage Technical Debt

Make It Visible

Untracked debt becomes permanent.

Track it:

Jira tickets labeled “Tech Debt”
Architecture backlog
Code comments with ticket references (not TODO graveyards)

If it’s not visible, it won’t get prioritized.

Distinguish Good vs Bad Debt

Ask:

Did we choose this consciously?
Does it still serve a purpose?
Is the interest acceptable?

Sometimes debt is fine if:

The feature might be removed
The system is temporary
The cost of fixing exceeds benefit

Pay It Gradually (Best Strategy)

Don’t schedule “Refactor Everything” sprints unless architecture is collapsing.

Instead follow the Boy Scout Rule (from Clean Code):

Leave the code cleaner than you found it.

While adding features:

Extract methods
Rename variables
Reduce duplication
Add missing tests

Small continuous improvements beat massive rewrites.

Refactor When Touching the Code

Best moment to reduce debt:

When modifying the same module
When adding related features
When fixing a recurring bug

You already understand that area — cheapest time to improve it.

Protect With Tests First

Never refactor risky areas without:

Unit tests
Integration tests

Tests reduce refactoring fear.

No tests → write minimal safety tests first.

Measure the Impact

You don’t manage what you don’t measure.

Signals of growing debt:

Deployment frequency decreasing
Lead time increasing
Rising bug count
Growing PR size
Developers avoiding certain modules

If velocity drops over time, debt may be the cause.

Avoid the Rewrite Trap

Full rewrites are often:

Emotionally satisfying
Technically risky
Business dangerous

Most large rewrites fail because:

Requirements change
Hidden complexity emerges
New system accumulates new debt

Prefer incremental refactoring.

Practical Backend Java Example

Bad debt pattern:

@Transactional
public void processOrder(OrderRequest request) {
   validate(request);
   User user = userRepository.findById(...);
   inventoryService.checkStock(...);
   paymentService.charge(...);
   emailService.send(...);
}

Over time:

More conditionals added
More dependencies injected
Harder to test
Bugs appear in edge cases

Managing debt here might mean:

Extracting orchestration layer
Moving business rules into domain model
Introducing events
Reducing transaction scope
Writing focused unit tests

When to Pay Debt

Pay it when:

It slows feature delivery
It causes recurring bugs
It blocks architectural evolution
It increases onboarding time
The interest > business value gained

Don’t pay it when:

Code is stable and rarely touched
System will be deprecated soon
Business priorities are elsewhere

Senior Engineer Mindset

Technical debt isn’t a failure.

It’s:

A trade-off decision
A business conversation
A risk management problem

The real problem is unmanaged debt.

Caroline Lima

Technical Debt