Software Engineers: Pay Attention to Salesforce

If you ever want to gauge how passionate the Salesforce community is, take a look at Dreamforce. You will find thousands of excited nerds sporting hoodies, bags, and other Salesforce goodies getting all fired up about new features. The enthusiasm is infectious; I myself who once harbored an irrational animosity towards laptop stickers now sport a Salesforce cloud on both my laptop and phone.

I started my career with .NET and JavaScript. When given the opportunity to work with Salesforce, a platform that described itself as “low-code”, I was hesitant. I love writing code. Low-code is a word that’s more suited to trigger a fight-or-flight response in people like me, not win over.

As I embarked on a journey of self-discovery, however, I learned that my love for a bigger paycheck was stronger than my fear of low-code.

As I started discovering the power of the platform and the opportunities for technical depth it provides, my concerns started disappearing quickly. Well past the fear, I’m now someone who would enthusiastically go knocking cubicle to cubicle asking people if they have a moment to talk about Salesforce.

There are many like me. But also many that are not. Salesforce often struggles to win over software developers — especially developers not deeply involved with the platform. While some developer dissatisfaction is driven by the platform’s limitations and quirks, I believe a lot of it exists simply because the platform is, as we will discuss below, misunderstood.

Regardless of where low-code and Salesforce fall on your avoid-o-meter, there is good reason to be paying attention to what’s going on. Contrary to the marketing hype claiming that low-code means no more developers, the low-code world is in desperate need of software developers. The prospects for talented developers today couldn’t be better.

So what’s going on?

Salesforce has not stopped growing and it doesn’t look like it will stop any time soon. Research firms like Gartner and Forrester project high growth for the low-code industry, with Gartner predicting that 75% of companies will be using at least 4 low-code platforms by 2024 and naming Salesforce as a leader, and Forrester placing accelerated low-code adoption at the top of its 2021 predictions. Markets And Markets projects the low-code industry to grow from USD 13.2 billion in 2020 to USD 45.5 billion in 2025. According to IDC, the Salesforce ecosystem is expected to create 4.2 million jobs between 2019 and 2024.

Numbers like that warrant attention.

Developer satisfaction and technology success

The struggle Salesforce has with winning over developers reminds me a lot about JavaScript a decade or two ago. With React, TypeScript, Node.js, and a lot of other fancy tech, JavaScript is finally cool. “This is cool”, however, was hardly the sentiment among developers around me at the time. Most expected and wanted it replaced with a “real” language and for that reason avoided it.

Yet, JavaScript continued to grow. Developer dissatisfaction did not stop it from taking over the world. Why? Because JavaScript delivered value.

While many worked on the cross-platform development dream, JavaScript ultimately delivered it because it could run on anything with a web browser. And a web browser was everywhere. The nights I spent sobbing in a pillow trying to figure out object-oriented JavaScript did nothing to change that fact.

Working with Salesforce today, I can draw many parallels. It delivers a lot of value in the form of accelerated delivery and empowering “citizen” developers, but at the same time struggles to win over a lot of software developers.

Developers have reasons to be dissatisfied. One reason is technological limitations. Salesforce did not work well with source control for a long time, deployments have been ridiculously complicated, and logging and debugging still has a long way to go. Developers love these things. Any platform that does not provide them is going to be frustrating to work with.

The good news is that Salesforce has been very aggressively addressing them as part of a push towards developer experience. Another good news is that developers who are around for the show and contributing to the solutions, just like the developers who were around for the show with JavaScript, will greatly benefit.

The second reason for dissatisfaction, and in my opinion the bigger reason, is that the platform is just misunderstood. My Pluralsight course Salesforce Platform Fundamentals for Developers discusses these at length: Salesforce requires a very different approach to software development, and not approaching it correctly leads to problems and frustration.

The World’s Most Misunderstood Platform

Douglas Crockford called JavaScript “The World’s Most Misunderstood Programming Language”. The same appears to be true for Salesforce and for low-code platforms in general. Both among developers and everyone else, they appear to be the world’s most misunderstood platforms.

Let’s address a few of these misunderstandings.

The Rise of “Anyone”

You may have heard the marketing hype. With low-code tools, anyone can now build software — no Software Engineers required!

Sure.

Armed with WebMD, anyone can also be a doctor.

True to some extent, but if the fever isn’t going away you still need the doctor.

I don’t want to downplay the power these tools place in the hands of end-users. They truly do get end-users from building spreadsheets to building their own software. What is important to note is that these are software solutions simple enough to be built by point-and-click tools. Most of these solutions would be similar in complexity to a spreadsheet.

There is a reason low-code rather than no-code is the buzzword. Any solution beyond simple will require code. While low-code tools do create a wonderful opportunity for citizen developers to dabble into code, you still need people who can write maintainable code. Take a look at the Sample Gallery at Salesforce Trailhead for an example. I picked the “E-Bikes” app: There’s no way “anyone” is going to write these Apex classes, these JavaScript-based web components, or even manage it all in a git repository let alone worry about security, error-handling and performance.

Low-code tools can be incredibly effective in the hands of skilled and experienced developers.

Revolution and Evolution

In 2014, Forrester Research coined the term “low-code” to describe this new rising category of software development platforms. As a developer, you would notice many similarities to tools you may have used in the past.

In my opinion, the real revolution in 2014 was not the platforms, but the marketing world’s discovery of a magic phrase to sell these tools to executives who pay people 6-digit salaries to write code.

Don’t get me wrong — the evolution of these tools has been fantastic. Modern low-code tools like Salesforce are powerful and in addition to delivering software fast, they address many of the problems surrounding maintainability and performance that plagued tools of the past. But the fact is that the idea of using visual tools to speed up development is not new at all. It has been around ever since the capability to build visual tools has been around. CASE tools, RAD tools, code generators, UI builders all shared that goal. In fact, even the idea of allowing non-programmers to create their own software solutions isn’t new.

As a developer, I see modern low-code tools as a natural evolution and improvement of these tools of the past.

Microsoft’s Visual Basic 6, while not the first tool to attempt it, is the earliest low-code success story I can think of. A point-and-click interface with an easy-to-understand language and a plugin-based system enabled quick delivery of software and opened doors for people who weren’t skilled programmers. I myself, a middle-school student at the time with barely any programming knowledge, was able to hack things together.

Wordpress, another example from the mid 2000s, could well be classified as a low-code tool. A lot of no-code capabilities to build a specific class of software (content-based websites) with the ability to extend through code using a plugin-based system.

Oracle Application Express (APEX), which dates back to early 2000s when it was known as HTML DB, is another example. They were marketing the same idea in 2004 for instance, but did not have the word “low-code” in there. The phrase they do have in there, however, will make all marketers collectively cringe: declarative development tool.

Good luck selling declarative development tools to the suits in the ivory tower.

They have learned the lesson now: The magic word “low-code development platform” now appears in the first sentence of the Oracle APEX landing page along with other executive-grade phrases such as “20x faster” and “100x less code”.

New Ways of Working

A common reason for developer dissatisfaction is that building solutions with Salesforce is very different from building solutions with .NET, JavaScript, C++ or the like. This centers around the fact that low-code platforms trade flexibility for rapid delivery, and our ways of working are very much modeled to take advantage of the flexibility that development environments provide.

For instance, we’re used to building user-interface wireframes before jumping into development, but that doesn’t always work very well with Salesforce because Salesforce puts together most of the user interface for us. Regardless, I’ve seen the pattern many times: put together wireframes, realize Salesforce doesn’t agree with the wireframes, write completely custom-coded pages in Salesforce to get around the lack of flexibility, and finally sob in the corner bathroom stall. What might work better, instead, is rapid prototyping.

The rapid delivery for flexibility tradeoff also means all stakeholders need to be on board with it. End users, product owners, business sponsors all need to understand that we may often have to choose a Salesforce way of doing something as opposed to custom-coding an alternative just to get a solution out there fast.

Knowing the platform deeply and it’s intricacies matters a lot too. As a .NET developer, I did not always have to know details about specific features. I just needed to know enough to know what to Google when the time comes. With Salesforce, however, it is important to know a lot of detail about features because decisions on whether to use out-of-the-box components/features or custom-coding often come down to knowing these details. Opting to go with out-of-the-box Salesforce components and learning about their limitations the hard way is a common pitfall and could put you in that corner bathroom stall again.

Low-code is changing the software delivery landscape, and developers are desperately needed. Not only because code still does and will always require expertise, but also because citizen developers who have the opportunity to jump into the world of code need guides and mentors.

The platforms are evolving fast too. Salesforce, for example, recently launched Lightning Web Components, a web development framework based on the Web Component standard. As part of Salesforce DX, Salesforce also enabled source-control integration that finally works. Salesforce Functions, a feature currently in pilot, will allow developers to write serverless containerized functions in their language of choice to extend Salesforce apps. All of these new developments are ripe with opportunities for talented developers to not only whet their appetite for technical depth, but also to evangelize, build upon, and shape the direction of the platform.

Dan Appleman, a former Microsoft MVP, took advantage of such an opportunity when he authored the most well-known book on Apex programming. Andrew Fawcett probably wasn’t too thrilled about the lack of good design patterns and practices in the Salesforce world — so he wrote the book about it. David Liu took the opportunity to build a website teaching newcomers how to code in Salesforce and expanded it to a series on Pluralsight.

As the Salesforce Platform continues to grow, we will continue to see the addition of more and more programmatic capabilities targeted at developers and these will continue to present great opportunities for developers.

The landscape is changing — and developers who are paying attention will benefit.