Salesforce Development: When tasked with working on the Salesforce Platform, engineers often react with a mix of dread and confusion about what Salesforce truly entails. Historically, only SharePoint development has a worse reputation, as indicated by numerous Stack Overflow Surveys.
I have been working for a number of different clients on the platform since 2011 and witnessed firsthand how Salesforce has evolved over the years. I aim to show why Salesforce development can be agile, fast and even (whisper it) fun.
What is Salesforce?
From a product perspective, Salesforce is a Customer Relationship Management solution that focuses on areas such as sales, support and marketing. From a developer perspective, Salesforce is all about data.
You create the data structures in the back end, control access to who has access to and can modify that data, build out business logic and integrations, and ensure that end users can interpret the data correctly through UI views, reporting and analytics. Obviously there are a lot more bells and whistles, but that’s the gist.
Revitalizing UI: Salesforce’s Lightning Response
One of the classic criticisms of Salesforce was that its UI was tired and stuck in the late 2000s. The company responded by launching the Lightning Platform, an app-centric platform that provides typical business flows out-the-box while allowing for the possibility of heavy customization where necessary.
Development has switched from the traditional JSF model (Visualforce) that required multiple round trips to the server to a component-based, lightweight framework (Lightning) that has more in common with React and Angular. And the recent launch of Lightning Web Components makes this even better.
Also read: Insights with Salesforce Einstein: Building AI Apps with Unstructured Data
Easy to code, difficult to code well
Salesforce does a great job at abstracting away some of the boilerplate that’s required in other applications. For those who don’t have a coding background, they can get far just by using point-and-click tools.
If you are a Java developer, you can get things working in Apex right away. Want direct access to the database from the business layer? You got it. Want to update permissions directly in the environment without worrying about pesky things like change management and version control? No problem.
However, when the application starts to mature and feature requests build up, this lack of separation of concerns will come back to bite you. Likewise, if you don’t pay attention to governor limits, what works in your sandbox can suddenly start failing in a production org with more data. If you don’t get things right from the beginning, fixing it later requires far more time and resources.
I’m not slacking, my code’s compiling!”
Writing code and pushing it to an environment where you could actually see it working used to be a painful process. I can acutely remember the days when you hit save and had to wait for ages while the Eclipse plugin compiled and pushed your code. Even worse was when you were sharing an environment with other developers or admins and had to worry about conflicts or replicating those changes in version control.
That’s why SalesforceDX was such a massive improvement when it launched a couple of years ago. For the first time, you had a CI-friendly, CLI-driven development process that could spin up an environment in seconds, push the code from source control, and run unit tests and UI tests to ensure you haven’t broken anything with your changes. Unlocked packages are a great way to modularize your code and explicitly specify dependencies.
All in all, developing on the platform has been completely transformed for the better! Now I just need to remember to fill out that survey…
