The short version: technical debt gets paid down when it is attached to work someone already wants done, and not otherwise. A dedicated cleanup sprint gets cancelled the first time a deadline moves. The durable method is a rule that every change leaves its area slightly better, plus one measured thing per quarter that you actually finish.
Start from an inventory, not a feeling
“The org is a mess” is not actionable and it is not persuasive to anyone holding a budget. Six countable things, each a query or a report:
- Custom fields with no data in any record
- Apex classes with under 50 per cent coverage, and classes with no assertions
- Flows and validation rules that are inactive
- Objects with more than one trigger
- Hardcoded IDs in Apex, flows and formulas
- Permission sets assigned to nobody
Each gives a number that can be tracked, and a falling number is the only evidence that pays for the next quarter’s effort. The full method is in taking a technical debt inventory.
Rank by what it costs you now
Not by how untidy it is. Three questions per item:
Does it slow down every change? Four triggers on Opportunity means every Opportunity change needs four things understood. High cost, pay it down first.
Does it risk an incident? A hardcoded record type ID works until the next org. An Apex class with no assertions passes while broken.
Does it only offend? A field named New_Status_2__c that works fine is a cosmetic problem. Leave it, and stop letting it upset you.
The third category is where cleanup efforts usually start, which is why they usually stop.
Attach the work to work
The rule that actually holds: when you change an area, leave it better than you found it, within the time you already had. Touching a trigger handler, add assertions to its tests. Editing a flow, fill in the description. Adding a field, delete a dead one on the same object.
This is invisible on any roadmap and it compounds. A team doing it for a year has a materially different org from one that scheduled two cleanup sprints and completed neither.
One measured thing per quarter
Alongside the continuous version, pick one item, measure it, fix it, and measure again. “Opportunity had five triggers and now has one” is a finished thing you can point at. It builds the case for the next one in a way that “we did some cleanup” never does.
Keep the scope small enough to finish inside the quarter with room for it to go wrong. An ambitious paydown that is 70 per cent done at quarter end is often worse than not starting, because the org is now in two states.
Deleting things safely
The blocker on most cleanup is fear, and the fear is reasonable. A sequence that removes it:
- Find every reference. Retrieve the metadata and grep for the API name. This finds formulas, flows, Apex, layouts and reports.
- Check the data. A field with values somewhere is a different decision from one that is entirely null.
- Remove from layouts first, and wait a release. If nobody complains, nobody was using it.
- Then delete. Recoverable for 15 days, which is the safety net that makes the whole thing tolerable.
Step three is the one people skip and the one that makes the rest safe.
Stop creating it
Paydown without prevention is a treadmill. The prevention is mostly in review: a second pair of eyes on a new field asking whether an existing one would do, and a CI check for the mechanical things such as hardcoded IDs and missing sharing keywords.
Those checks are cheap to write and they never get tired, which is more than can be said for a reviewer at five o’clock.
Frequently asked
How do I get time approved? With the cost, expressed in delivery terms. “Every Opportunity change takes two extra days because of the trigger situation” is a business case. “The code is messy” is not.
What if nobody knows why something exists? Treat unknown as a finding. Removing from layouts and waiting is how you find out safely.
Should I rewrite or refactor? Refactor, nearly always. A rewrite means two systems for a while, and the second one acquires its own debt before the first is gone.
