TL;DR | The Highlights
- “Small change” is one of the more misleading labels in Salesforce development. A few lines of code can sit in the path of a much larger set of business behaviours.
- The right way to size technical risk is not by the amount of code being changed, but by the blast radius of the behaviour being changed.
- That means the work starts before the code does: trace the process, understand dependencies, find where the same business logic appears elsewhere, and determine what must (and must not) change.
- Spending two hours understanding a system before making a five-minute change is not overengineering. Sometimes, it is precisely what makes the change a five-minute task.
- Mature Salesforce teams optimize for predictability, not simply speed. The best deployment is often the one nobody notices except for the behaviour it was supposed to fix.
“This is just a simple Apex update.”
In Salesforce development, that sentence should probably make you ask more questions, not fewer.
Sometimes, it’s natural to associate the size of an edit with the size of its risk. One line feels safer than 100. One field feels easier than an entire flow. One condition in an Apex class looks like something that should take a developer a few minutes to change.
Sometimes it does.
But the number of lines being changed tells you almost nothing about how much of the business can feel that change.
That distinction matters because mature Salesforce environments are interconnected by design. Apex sits alongside flows, validation rules, integrations, reporting, permissions, managed packages, and years of accumulated business logic. A condition that looks isolated in code may actually sit in the middle of a process that stretches well beyond it.
So we think “small change” is often the wrong way to frame the work. The better question is: how large is the behavioural blast radius?
That idea came up repeatedly in conversations with Ray Harvey, a Salesforce Developer at Lane Four, as we unpacked what a senior engineering mindset actually looks like during day-to-day delivery.
It is rarely about writing more code. More often, it is about understanding more of the system before writing any.
Stop Sizing Risk by the Diff
A code diff tells you what changed in the repository. It does not tell you what changed in the business. That is an important distinction.
Imagine a single condition determines whether an opportunity can progress, whether a record gets passed to another system, or whether an automation fires. Changing that condition may require only a few characters of code.
But that same business rule may be referenced somewhere else. Another automation may expect the previous behaviour. A report may depend on the resulting data. An integration may assume a particular state before processing the record.
The technical edit is tiny. The behavioural surface area is not. That is why line count is a poor proxy for complexity.
The size of a change should be measured by how much behaviour it can influence, not how much code it takes to implement.
Once you adopt that lens, “simple” requests start getting better questions.
Where does this process begin? What happens immediately before and after this condition? Where else is the same rule evaluated? Which systems consume the result? Which existing guardrails are intentional? And perhaps most importantly: what behaviour are we explicitly trying not to change?
That last question is easy to overlook.
Good engineering is not only about making the new behaviour work. It is about preserving everything that should continue working exactly as it does today.
The Five-Minute Change Might Require Two Hours of Work
We saw this recently with an Apex update that, viewed purely as a coding task, was almost trivial. The obvious change could have been implemented in minutes. So we did not start there.
First, we traced the process upstream and downstream. We searched the codebase for every place the same business condition was evaluated. We mapped which guardrails needed to change and which ones needed to remain untouched.
That investigation exposed something the original request did not: under a particular scenario, the seemingly simple change could introduce nondeterministic behaviour.
The code was not difficult. Understanding what the code needed to guarantee was.
So we made the expected behaviour explicit and deterministic first. Only then did we make the Apex change.
Roughly two hours of understanding. About five minutes of code.
At first glance, that ratio can look inefficient. We would argue it is the opposite.
Those two hours were not overhead surrounding the change. They were the work required to know that the five-minute solution was actually the right one.
There is a broader lesson there for how Salesforce work gets estimated, too. The effort required to type a solution and the effort required to safely deliver one are not the same thing. If teams estimate only the former, “small” requests will routinely appear to take longer than expected. In reality, the estimate may simply have ignored the most important part of the job: understanding the system well enough to change it safely.
Testing the Change Is Only Half the Job
The same principle should shape testing.
- A narrow definition of success asks: Does the new behaviour work?
- A stronger definition asks: Does the new behaviour work while everything else continues to work?
Those are very different standards.
Before this particular update moved to UAT, it ran against several test classes across the surrounding layers. The objective was not simply to prove the new Apex behaved correctly. It was to test the assumptions we had made about its blast radius.
The deployment ultimately passed 28 Apex tests. That number is useful, but the more important outcome was much less exciting. The requested behaviour changed. Nothing else did. That is what successful development often looks like from the outside: remarkably uneventful.
In Revenue Systems, Boring Is a Feature
There is a tendency in technology to celebrate the visible parts of system architecture and custom development: the new feature, the clever solution, the major implementation. But for systems that sit underneath revenue operations, some of the best engineering produces almost nothing worth talking about.
- No unexpected downstream behaviour.
- No mysterious regression two weeks later.
- No seller discovering that a previously unrelated workflow suddenly stopped working.
- No operations team trying to trace a data issue back through five different automations.
Just the intended change, behaving as expected. That kind of boring is not a lack of sophistication. It is evidence of it.
A predictable Salesforce environment is one where changes can happen without creating uncertainty about what else might move with them.
And predictability becomes increasingly important as the platform expands. More automation, more integrations, more clouds, more AI, and more business processes running through Salesforce mean the behavioural blast radius of individual decisions can grow even when the code itself does not.
That makes understanding dependencies more important, not less.
Predictability Is an Engineering Choice
None of this means every one-line change needs two hours of investigation. Sometimes a five-minute change genuinely is a five-minute change.
The discipline is being able to establish that before you make it.
That requires moving away from a development mindset that asks, “How quickly can we make this change?” toward one that also asks, “What do we need to understand to know this change is safe?”
For us, that is part of what mature Salesforce solutioning looks like. Your Salesforce instance should be one of the most predictable assets in your revenue stack. It should behave the way the business expects today and continue behaving that way as you evolve it tomorrow.
That reliability does not come from avoiding change. And it does not come from treating every change as enormous.
It comes from sizing risk correctly. Not by the number of lines you touch, but by the amount of behaviour those lines have the power to change. Because when the system supports your revenue operations, “nothing else changed” can be one of the best outcomes an engineering team delivers. If you want that level of attention applied to your Salesforce environment, let’s chat.
Let's chat!
