Do you want a No-Code project? Train your developers

Do you want a No-Code project? Train your developers

Recently inside the Dynamics community there is an ongoing discussion if it is useful or not for a consultant to have coding knowledge (links here and here).

As most of the buzz comes from non-developers I decided to chime in. First thing I would like to do is to shift the focus from a Team/People point of view to a Project point of view. I wrote intentionally the word project inside the title of this post because the project (or call it implementation if you like) should be in my opinion the core of the discussion.

Someone can interrupt me and says: "CRM is an ongoing process, you need to adapt to the changes,..." I agree, but the word ongoing implies that we have something to actually thrive the process, this something is not just the CRM itself but also the project that shaped the CRM to the customers' needs.

Every CRM project needs a developer? No

Back to Dynamics CRM 4.0 I would probably reply yes or maybe, but we are in 2018 and the Dynamics 365 Customer Engagement platform can host a successful project delivered by people with zero code experience.

You already delivered a No-Code project and the customer is happy? Great! And trust me, also your developers are very happy of this news.

Note: Which is (in my opinion) the OOB feature inside Dynamics that made possible this? Synchronous Workflows (and no, Business Rules ARE NOT a good example for this pitch)

My customer doesn't want custom code

If you worked on some CRM projects I am sure you already met the "No Custom Code" customer. There is nothing wrong if the customer asks to don't have custom code that probably needs to be maintained and updated when the next major update will arrive, but is up to the consultant to stand up and draw a line. If for example you have a requirement that can be implemented easily with just a plugin but a no-code solution requires

  1. Creating two entities
  2. Five workflows
  3. A recurring Bulk Delete job

I will ask myself a couple of questions before proceeding.

Note: Avoiding custom code doesn't protect you from deprecation, like having 200 Dialogs for example.

This project requires custom code

Are you sure? Or are you just having a "Custom Code Syndrome"? The symptoms can vary, some of them are:

Developer symptoms

  1. Functionality X can be implemented only by custom code. Did you check if this is still true? Your customer just subscribed to Dynamics 365, he has version 9.0 and maybe there is an OOB feature now.
  2. We can finish the project sooner if we use custom code. So you are actually saying that there is a no-code way but you think it is not worthy. Are you able to quantify the difference in terms of time and complexity in order to justify your choice?

Consultant symptoms

  1. We already implemented X for Customer Alpha, we can copy/paste for customer Beta. I am a big fan of reusing code, but are you sure that the Functionality X is 100% what actually customer Beta wants? Just a small difference (like a a couple of fields involved) can increase the amount of time required to reuse a piece of code, time that maybe would made a difference for the 2nd developer symptom.
  2. If we create this custom code we don't need to buy this third-party solution. So instead of buying a 50$ add-on with 1 year free support, you would like me to spend 5 working days to recreate the add-on with less functionalities? Are you sure? Ok...

Note: some requirements are well-known for requiring custom code, like copying product details to special entities like opportunity products, quote products or invoice products.

A consultant should have coding knowledge?

I appreciate people with different skills, but a consultant with some coding skills (and we should check the level and if related to Dynamics or not) is not a must-have for a Dynamics project.

In my opinion is important to have consultants valuing the opinion of developers at any stage (and not only when arrives the moment "we don't know how to do this, unleash the developers") but more important is to have developers with an up-to-date training. For a developer is very easy to choose the Custom Code path because it is the daily job routine and he or she feels confident to deliver, but with a proper training developers can be aware of the new OOB capabilities and learn how to exploit them.

It is true, these new functionalities often replace old custom code, but they can be also extended by new development, creating an ongoing process of skills where everyone inside the team benefits from, also in a No-Code project.

Thanks for reading!

Are you a Microsoft Dynamics professional? Subscribe to Dynamics Weekly to receive a curated list of articles and other resources related to Dynamics 365 every Monday directly to your inbox.
Olena Grischenko

#She-In-Tech * #PowerLabs * Power Platform Architect and CoE Advisor * Power Platform Ops👑* 5x Microsoft MVP for BizApps * NV1 * CEO at Technomancy Pty Ltd.

6y

Thank you for your post. You've got some of my favourite scenarios covered :) The only thing, I have a question about the title of the article: why do you think dev make those decisions themselves to code or not? In an old fashion CRM project type it's a functional or solution architect to tell a developer:"We need a java script here. " Is there still projects like that? It depends on a size of a project, of course. But for a big Scrum one its never a single dev call. Team grooming, team estimating, a product owner.

To view or add a comment, sign in

Insights from the community

Explore topics