Developers are often tempted to start writing code to fix new problems as they are discovered.  However, in the Dynamics 365 CE world, this behaviour can often cause problems and add costs for the future.  While there are definitely times when writing code is necessary, let’s take a look at some important things to consider before writing your first line of code.

Maintenance

First, let’s tackle the issue of maintenance.  Remember this: every piece of code written becomes a maintenance point.  This code should be version-controlled, checked, tested, and, if needed, updated on every release of Dynamics 365, even if there have been no changes to your code.  This is because Microsoft is constantly making additions and changes to their model (and sometimes deprications), and just because your code didn’t change does not mean it will work the same way when 365 is updated.  For this reason, coding should always be a last-resort. Only code when there is no non-coding way of solving the problem.

Who is the User?

A very important question to ask is “Who will be responsible for making changes in the future”?  First, look at the size of the organization using the solution. Are there dedicated staff for making changes to 365, or are there a few part-timers who act as power-users or citizen developers?  This is an especially important question for developers that work contractually. You may not always be there to maintain your own code, so find out who will be responsible for the solution and what their competencies are.  If the resources are not there to maintain any code, it is imperative to find a non-coding solution or convince the organization of the necessity of keeping some developers on call.

What’s Already There?

In every new version of Dynamics 365, there are additions and changes.  This can affect developers in two ways.

1. It is possible that a feature that solves the problem already exists.  Be familiar with the Dynamics 365 SDK and what is included in each version.  There is no sense in reinventing the wheel and creating maintenance points if a standard entity can be used with none or few modifications.
2. It is possible that a feature has recently been added that duplicates custom functionality already in your codebase. If so, consider modifying your code to include the new features and deleting any duplications.  Remember, this will save time and money in the future as Microsoft is responsible for maintaining their code and not you.

How Much Time Will It Take?

One important factor for how long it will take you to code a solution is your experience.  Writing code for apps and plugins can take a long time and cause massive headaches if anything goes wrong.  If you are lacking in time or experience, consider a non-coding solution. For example, PowerApps and MicrosoftFlow work together to let a developer quickly develop mobile applications and move data between a mobile device and a server without needing to spend months learning new languages and without the risks of avoidable mistakes.

Summary

We have looked a a few reasons why it can be advantageous to not code a solution.  In the next post, we will consider times when coding is necessary and how to approach solutions with that in mind.