Saleforce is an example of a low code platform — business applications can be created via visual tools without needing to write a single line of code. Of course there is code required to build these tools, and the configuration that is created through these tools will eventually be loaded by code, but from the end user’s perspective none is required.
While these applications will work fine, they will typically not be the most streamlined — that’s the tradeoff. For example, with a coded solution I can create a complex page to carry out multiple actions, reacting to the user’s inputs to show or hide specific sections.
So which way is best? Or to put it another way: To code, or not to code, that is the question.
There is no right answer — and this is coming from someone who loves coding — deciding whether to go with a coded solution depends on a number of factors:
The skill set of the team creating the application.
While it’s useful to get your team learning new skills, creating a business application using technology that none of them are familiar with is introducing quite a level of risk.
The skill set of the team that will be maintaining the application.
I’m always surprised by how often this aspect is forgotten about in the excitement of developing a code-heavy application with loads of bells and whistles. If it can’t be maintained going forward then it’s highly likely that it won’t get used. Additional features will be required and if they can’t be added by the team in situ, it’s likely that something else will be created and eventually enough functionality will live elsewhere and users will forget about it.
What the customer wants
You’ll often get a good steer from your customer as to what they way. Some will mandate configuration only and accept that some tasks require a number of steps and screens, others will want the slickest experience possible, with users doing the minimum amount of work and being guided all the way. Most will want something in between —typically configuration unless it means a lot of work is pushed onto the user, the dreaded Salesforce tax that means it takes them longer in their new application than it did the old way! Many customers will be new to Salesforce, so rather simply following their instructions and then pointing the finger at them when the user is unhappy, make sure to spend some time explaining the pros and cons of the different options. Coded aspects to a solution don’t have to be inflexible, things like custom settings/metadata types and field sets allow admins to retain some control.
Beware the Zealots
In any situation like this you will always find people filled with evangelical zeal, convinced that theirs is the one true way and entertaining no arguments to the contrary. You can’t reason with these people — like any true evangelist, they act according to their beliefs and are only interested in converting you, not listening to your arguments and making an informed decision. You should always be prepared to challenge them, otherwise you and the users will be forced down the wrong path and come go-live day, nobody will remember that you looked slightly uncomfortable with the way that things were going.
When to code?
The advice I’ve always given to my colleagues at BrightGen is that you don’t code until it’s time to code, and then you code. Knowing when it’s time to code is something that comes with experience, but when that time comes you get on with it rather than worrying if it’s the right thing to do. You don’t want premature coding, but you do want to code when appropriate.
I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 6 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring.
Brightgen Careers | Brightgen
For 10 years organisations have relied on BrightGen to show them what Salesforce — and their business — is capable of…
You can find my (usually) more technical thoughts at the Bob Buzzard Blog