To code or not to code? It’s an important consideration in the app creation process and an inevitable one for organizations looking to gain competitive advantage in the market.
When code is considered, it’s because there is a need to customize or create an app, feature, functionality, or design that is not possible with the out-of-the-box product. The power of code is extraordinary. With the right talent and time, pretty much anything is possible.
As a presales engineer, I engage with customers and prospects to learn more about what they are trying to achieve and more importantly, why they are trying to achieve it. I used to think the “code or no code” consideration was a competitive question—that companies either do one or the other. However, working with our customers, I’ve realized there is much more nuance to the consideration. Most of the time, it’s less a question of if and more a question of when.
When and why to code.
In recent years, the answer to “when to code” has changed. Lightning now gives builders the ability to create a variety of complex apps declaratively. The product team at Salesforce continues to enhance declarative functionality in the product and encourage builders to leverage it. In Trailhead as well as in the exams for Salesforce certifications, you will frequently see some version of the following (this is a quote from a Trailhead Module on Flows):
“It’s best to start with declarative, no-code tools and work your way up to code solutions, so we avoid building a Lightning component, which requires coding.”
Salesforce’s innovation is intent on pushing the “when to code” answer further down the timeline by providing declarative tools for development.
Skuid was created to complement Salesforce’s recommended best practices for low-to no-code app development by giving developers and admins the ability to extend the “when to code” answer even further. The declarative nature of the Skuid toolkit allows builders to get the apps and functionality they need even faster, massively speeding up time to market and iterations. This allows organizations to get to value faster (turns out, it’s a LOT of value - check out this “total economic impact" report by Forrester).
Solving real app development problems with a declarative-first approach
One of the coolest experiences of my career so far was building an app to solve an extremely urgent asset tracking problem for a branch of the military. They had a pen and paper process for tracking the lifecycle and maintenance of assets. As a result, they had no visibility or insight into where the assets were, the condition they were in, and who had used them. This caused many significant problems for them, including, a tragic and preventable casualty.
The customer moved the process to Salesforce Lighting and all the data to Gov Cloud. However, they hit an adoption and usability wall in the middle of the app creation process. Their unique process for asset tracking required 49 clicks using the standard schema-based interface. This was a non-starter for them since efficiency and app usability were critical for their end-users, who were often using the app while in the field. Instead of writing code, they chose to recreate the application declaratively using Skuid and Lightning.
The “Skuidified” app took the 49-step process down to five and was built without writing code in a total of about 20 hours. The “when to code,” in this case, was pushed out to a “not yet.” This was a big win for the military and allowed them to rapidly incorporate the solution without incurring any code debt.
Rapid iterations make for better low-to no-code apps and happy users.
Could their solution have been built using custom code? For sure. But their declarative-first approach paid off massively when it came to iterating on the app and incorporating user feedback. Salesforce’s recommendation that it’s best to start with declarative, no-code tools took on a new meaning for me when I visited our military customer on-site.
I got to watch end users actually use the new app for the first time. Frequently, one of them would explain something that was confusing for them in the app or articulate why they did something a particular way instead of the way the app assumed. Instead of taking notes to incorporate their feedback into the next code sprint, I hurried back to my laptop and made changes to the app immediately, using the Skuid drag-and-drop app composer. Upon a simple refresh of their screens, I would watch their faces light up as the app quickly evolved into something truly valuable for them.
Work smarter with code.
What do I think about code? Code is awesome! In my time at Skuid, my admiration for code has grown. But I’ve also seen real-world scenarios where starting with a declarative approach instead of immediately turning to code has paid massive dividends.
Declarative-first means you have resources available when you do decide to code. A good example of the “declarative-then-code” was an organization that was needing a very complex questionnaire spanning numerous custom and standard objects. Instead of building the whole app with code, their development team collaborated with Skuid to build almost the entire solution declaratively. They then extended Skuid with code to add a question randomization feature and a timer to the app. Writing code for laser-guided targeted solutions, instead of coding the whole thing (even if you’re using libraries) made for a much tighter feedback loop from users and speedy turnaround for deployment.
When you use Skuid to extend with low-to no-code app development, you're simply extending what is there. In other solutions, including Lightning, extending with code means you have to re-code all the things you already like about the declarative app, plus the feature or functionality you want to add.
The need to customize is not going away.
So, to code or not to code? The goal of low- to no-code app development is to make it easier and faster to deliver the custom solutions your customers and users need. If you have custom solutions that can’t be met with standard Lighting, the Skuid toolkit lets you extend the value of Lighting, pushing the “when to code” answer significantly farther down the road and freeing up valuable development resources for other projects where the “when to code” answer is now. Also, Skuid complements code by being fully extensible with Javascript or CSS so when it’s time to code, you can integrate it into your solution without issues.
The need for customization isn’t going away. Being able to customize your apps quickly, responsively, and at-scale will lead to delightful human-centered apps that are actually adopted by your users. Solve all the problems you can with standard Lighting, then solve your unique customization needs with Skuid, and then, when you have exhausted declarative options, bring in the code! It’s less a competition and more about knowing when to use the tools available. Lighting, Skuid, and code—together—provide a powerful, unified, and complementary development approach so that you can “start with declarative, no-code tools and work your way up to code solutions.”
Are you running into limitations with your out-of-the-box solutions? Try Skuid for yourself by signing up for the free account.
