A Tip A Day #33 – Click vs Code

This post is a part of the daily blog series 

A Tip A Day, daily dosage of learning!

A Tip A Day #33 – Click vs Code

Salesforce started out as a declarative platform during its inception and continues to provide a rich set of declarative features.  Salesforce refers to these features as “Point-and-click” which helps build the system without custom coding.

And we, salesforce developers, like any other developers love to code! After all, with custom coding, we are in full-control of what we are doing; we can build the framework we want; we orchestrate the triggers, classes and helper classes etc. and manage all of them at one place.  Wow, but wait, hold on!

---

“Why gather the flour, eggs, cream, butter, sugar and bake a cake when you can make use of the cake you have already bought?”

---

Well, with this post, I try to address this dilemma of “Point-and-Click” or “Custom Coding” by putting forward the factors you need to consider while making a decision for this compelling contest.  They are:

• Effort
• Functionality
• Usability
• Volume
• Maintenance

To address these 5 factors, you just need to ask yourself and address these questions before going with custom coding:

Effort:  Effort is the amount of time, the number of resources, and in turn the money you spend on building a feature.  Is it worth spending the “effort” on custom coding? Are you willing to spend efforts in writing test classes for the custom code you built?

Functionality: Does the declarative development cover all your requirements and all the functionalities you are expecting? Can you sacrifice on certain functionality when going with the point-and-click feature? How can you make use of the extra features the same point-and-click feature provides?

Usability: Does your custom coding come with the same “look and feel” of Salesforce layouts? Is it just as easy as just point-and-click in terms of usability?

Volume: Does your custom code handle all the volume of data and very importantly within the governor limits of salesforce? Is the code bulky-fied to handle the future increase in data?

Maintenance: How easy is it to make changes to your custom code in the future? Are you willing to put in extra efforts for future changes to the code and test classes as well?

If you have answered most of the above questions in favour of “point-and-click” declarative methods, you must go for it, otherwise custom coding is your way! If you are still in dilemma, I’d be very glad in helping you.  Comment or email to reach me.

It is also the responsibility of the development team to be fully aware of all the declarative features salesforce provides and to be up-to-date with the latest features Salesforce releases every quarter to help in making the decision.

What I suggest:

• Use Process Builder instead of Apex coding with Scheduled classes
• Use Validation Rules instead of Apex Triggers
• Use Workflows/ Approval Process instead of Apex coding
• Use Visual Flows instead of multiple Visualforce pages
• Use Formula/Roll-Up Summary fields instead of Triggers/Coding

In short “Point-And-Click, instead of Code”!

This post is a part of the daily blog series 

A Tip A Day, daily dosage of learning!