What Technical Debt Really Costs in Salesforce Commerce Cloud

When I first started my career, technical debt meant only one thing to me.

Messy code.

Methods that were too long.

Variables with bad names.

Duplicate code.

Things that looked ugly.

Over the years, my definition changed completely.

Today, when someone says technical debt, I don't think about code style.

I think about future problems.

Problems that don't exist today.

But eventually will.

How My Thinking Changed

Most of my learning didn't come from writing features.

It came from debugging.

Every production issue teaches something.

Sometimes the actual bug takes only a few minutes to fix.

The investigation takes hours.

That's where the learning happens.

You start asking questions.

Why did this happen?

Why wasn't this considered?

Could this fail somewhere else?

Eventually you stop fixing bugs.

You start preventing them.

That completely changed the way I review software.

---

Performance Is Usually the First Sign

One thing I've repeatedly noticed is that technical debt usually appears as a performance problem first.

Not because the code is incorrect.

Because it wasn't written for what the system eventually became.

A job processes every Custom Object.

During development there are 50 records.

Everything works.

A year later there are 500,000 records.

Suddenly the same implementation consumes more memory, takes much longer to finish, and becomes difficult to investigate.

Nobody intentionally created that problem.

The implementation simply never considered growth.

And that is technical debt.

---

Technical Debt Isn't Always Bad Code

One thing I enjoy during code reviews is asking:

"What happens if this system becomes ten times bigger?"

Many implementations work perfectly today.

That doesn't automatically mean they'll continue working tomorrow.

I've seen examples where:

• Database queries happen inside loops.
• Expensive operations repeat unnecessarily.
• Transactions don't consider failure scenarios.
• APIs return more information than they should.
• Third-party cartridges work functionally but introduce security risks.

Most of these implementations aren't broken.

They're simply designed around today's situation instead of tomorrow's.

---

Why We Create It Anyway

The interesting part is that technical debt isn't usually caused by poor developers.

It's caused by reality.

Deadlines.

Changing priorities.

Urgent releases.

Everyone has said something like:

"We'll improve it later."

Sometimes that's the right decision.

The mistake is forgetting that "later" eventually arrives.

---

What I Look For During Reviews

These days I spend much less time asking:

"Does this code work?"

Instead I ask questions like:

• Will another developer understand this next year?
• What happens if this throws an exception?
• What happens when there are one million records?
• What assumptions does this implementation make?
• Is this easy to maintain?
• Is there a simpler approach?

Those questions usually reveal much more than checking whether the code executes successfully.

---

Final Thoughts

For me, technical debt isn't about messy code anymore.

It's about engineering decisions whose cost hasn't appeared yet.

Sometimes the cost is performance.

Sometimes maintainability.

Sometimes security.

Sometimes an entire weekend spent debugging something that could have been prevented months earlier.

The earlier we identify those decisions, the cheaper they are to fix.

---

What's Next?

In a few days, I'll be publishing the public SFCC Cartridge Audit Registry on SFCC Tales.

One of the things every audit will evaluate is technical debt—not based on formatting or opinions, but on how likely today's implementation is to become tomorrow's problem.

I'm excited to share the first reviews.