As a Salesforce consultant you have probably heard the mantra before

No code on this project!

In this post we discuss when that approach can lead to a poor solution that doesn't achieve project goals and how you can get buy-in from key stakeholders when justifying writing code.

Flexibility and Balance

Whilst it might not be 'Best Practice' to write code, it does need to be challenged by the project and not followed blindly.

Good project teams are mature and experienced enough to understand the power that writing code can provide. Especially with respect to automation. Project teams that I have worked with in the past have always taken this design principle as a point of reference, i.e. can it be done with config first and if not we look at other options. Other options usually include trying to understand if there is a paid/free AppExhange solution. If not, then writing code to fulfill the requirements is looked at as a viable option.

There is a fine balance to be found and that is usually determined by the user experience. If the user has to click, click, click to complete an action then it might not be ideal. Ultimately, it will be them that tell you if they need code or not. When the end-users are told they can't have a feature or it cant be done a certain way because it requires code - then the project is doomed (in my opinion). An IT project especially business software, can only be successful if it is used by....you guessed it the end-users. Some argue that because its part of their job, users can be forced to use a system. I don't agree, people are smart, resourceful and accustomed to great user experience. But a crappy user experience in front of them and they will do crap work on it, or worse they wont do the work at all.

Even architecturally there can be valid arguments for going down the code route. An example might be a proliferation of workflow rules, this can become quite hard to maintain over time, would it be easier to have a trigger with all that logic maintained in code ? It would certainly make support easier. If you have the right resources that is.

Why organizations want a 'no code' implementation

Project teams usually cite a couple of main reasons for having this policy. They are usually a mix of the following:

  • Support
  • Cost
  • Time

However, organizations which focus entirely on the above tend to have a dim view of their end users and the importance of user adoption. In most cases, it is about educating the project stakeholders - a little bit of code can really simplify this process for your users. Which is usually enough.

How to justify writing code

When justifying to senior stakeholders why a particular feature needs to be implemented using custom code, you need to speak their language. This is usually in terms of cost/benefit analysis. If it would take a developer 3 days to implement a feature, then how many clicks would that feature save and how much time does it give back to the business to spend elsewhere. If this is analysis is articulated well, then it will be an easy sell. If that fails - walk away as you probably don't want to be involved in a project which is managed by such irrational individuals.