Go to portal
Since its inception Salesforce had a clear obstacle to overcome, which is clear to see in their first V2MOM:
V2MOM it’s an acronym which stands for Vision, Values, Methods, Obstacles & Measures, document to create alignment and common understanding across the organization.
Why was it an obstacle? Well, by the nature of how businesses evolve, digital solutions have a lot to do as an enabler to support that growth. At the pace of change we experience, the market can’t generate enough ready professionals for the exponential demand that is faced with.
I leave you here a link from a talk by ‘Uncle Bob‘ which explains why and how that obstacle will continue, also covers other interesting topics: https://www.youtube.com/watch?v=ecIWPzGEbFc
Over the years Salesforce narrative has evolved from No-Code to Low-Code and the never ending story of citizen development vs programmatic development.
Let me give you some pointers:
Drag & Drop
With the concept of citizen development you have what is often called configuration, things that you can accomplish with clicks, not code. On the other side of the spectrum, you have the latter which requires tooling to get ready, in the right version and synced to even start.
A quick reminder here to our previous post on the importance of Version Control.
Maintained, Extended & Upgraded
One of the things Salesforce also had very clear from the start is burden reduction and unsync of the core version of its product, they achieved that with cloud computing.
With declarative development you have your salesforce instances maintained, upgraded and extended not one, or two, but three times a year! Packaged up as major releases, full of enhancements and new functionality for you to use. No need to upgrade, install… nothing.
With functionality that you develop programmatically, this may require more care & refactoring.
Framework
With the tools that Salesforce gives us to develop with clicks, they provide not only the functionality but the framework to do so. It comes with what we could call forced modularity, which is a good thing in many ways. All of this is including the UI and integrations.
Think about when you change a page layout or via the App Builder, everything keeps working automagically. Providing us with this, is no small task.
Instead when you are developing in code that modularity is something you bake, it’s DIY.
Simpler vs Challenging
The golden rule for me is, seek the simplest way. If you can achieve it with the ready baked tools or functionality, go for it. Else, code.
With code you have a world of possibilities of customization, yet with clicks you have limitations.
However, “that you can, doesn’t always mean that you should”.
Watch out!
One of the things that often is called out as a benefit of declarative solutions, which I don’t particularly agree with, is the bypass of writing unit tests and worrying about test coverage.
Whilst I understand the thought that in the short term it saves time to market, it’s quite narrow minded and also sends out the wrong message.
Testing is essential, that includes unit and integration tests. You must care for your system landscape performance, and have a process in place to test your code continuously. I’d also argue that each functionality you touch should have ready baked monitoring and alerts. So you can ensure that your applications work as intended as the system and data changes, and evolves over time.
Conclusion
Last thought, in Salesforce you have a ton of ‘ready to go’ things, aka Out of the Box functionality.
So please don’t reinvent the wheel and always check what is readily available to you. Seek for native solutions. Don’t waste your time, effort and IQ with things that already exist and / or are easy to get out of the door. Instead, focus on more interesting and challenging stuff.
Over time minimizing technical debt and hassle.
One agile concept is ‘the art of maximizing the amount of work not done’. As a team you should be asking yourself with every piece of work: What is the simplest thing that could potentially do the job?This is also about the tools and functionality we leverage in Salesforce, let me point you to David Lui and Don Robins Play by Play Salesforce Knowing When to Code, which covers just this concept in a great way: Knowing When to Code in Salesforce, www.tiny.cc/lowcode
