Developing solutions for Salesforce is in some ways like putting together a Lego kit, only without a picture on the box or an instruction booklet inside.
You have to decide what it is that you’re going to build, and your vision is what becomes the picture on the box.
Salesforce gives us a powerful platform that provides all of the pieces we need to build game changing business systems, but it’s up to us to figure out what it is we want our solution to look like, where we can find the right pieces, and how to assemble everything into a working application that delivers business value.
A common pitfall for new developers is to try and do too much, often spending significant time trying to build new functionality that is already provided by the platform.
Let the platform do its job so that you can focus on delivering business value.
Don’t Reinvent the Wheel
In the not-so-distant past, IT organizations had to manage the many moving pieces of complex infrastructure and application architectures.
More time was spent on the overhead of operations and management than on creating value for the business.
Salesforce changed the game completely when it introduced the Force.com platform. Force.com is what we refer to as Platform-as-a-Service, or “PaaS,” and provides computing services as a level of abstraction that masks the complexity of the underlying architecture.
Salesforce takes care of all of the infrastructure for you, from network connectivity, to servers, to the database, to storage, to security, and beyond.
And not only does Salesforce manage all of the moving pieces “under the hood,” it also provides us with a rich platform for configuring and coding business applications at a level of abstraction that allows us to focus our attention on customizing what we get out-of-the-box and creating new applications to drive business agility.
Our job as developers is to ask the platform to do things on our behalf, either through declarative configuration, or with custom Apex, Visualforce and Lightning code.
It is difficult for traditional IT organizations to give up control, but it is time to stop trying to reinvent the wheel and let Salesforce take care of the infrastructure so that you can take take care of business.
Clicks vs. Code
Developers who are introduced to the platform by way of Apex, Visualforce or Lightning will typically take a code-first approach to solution design and development.
What many developers don’t realize is that there is a jumping off point between what can be achieved through “declarative” development – configuring out-of-the-box functionality using tools provided by the platform.
This “clicks vs. code” paradigm seems like a dichotomy between the “admin” and “developer” roles, but in reality it is the responsibility of every Salesforce developer and architect to know where declarative capabilities end and the need for custom code begins.
By using declarative tools for customizing the platform and developing applications, you are letting the platform do its job.
The platform is responsible for ensuring that your declarative customizations continue to work from one release to the next, and when new functionality is exposed by the platform it is readily available for deployment without having to refactor and redeploy code.
Salesforce developers who ignore the declarative capabilities of the platform do so at their own peril.
Developers who only know how to code will apply code based solutions to every requirement. When all you have is a hammer, everything starts to look like a nail, and this creates risk on a number of levels.
When I teach new Salesforce developers how to design and build solutions on the platform, there tends to be an aversion to doing anything declaratively as it is seen as a threat to their very existence. Why would you need coders if you can do so much with clicks?
This perceived existential threat is only compounded as more declarative solutions are introduced to the platform that replace what once required code.
This is not a threat. This is an opportunity.
We are always trying to shift things from the “programmatic” side to the “declarative” side of Salesforce development. We want to shift from high-code solutions to low-code or no-code solutions wherever possible.
Why? It’s not to replace the jobs of developers. In fact, the opposite is true.
The less low-value and commodity code we have to write as developers, the more we can focus on high-value code-based solutions that will make a positive and lasting change for our organization.
Try not to look at it as “clicks vs. code.” Embrace a philosophy of “clicks and code.”