Sage CRM 2020 R2: Developer Best Practices (Part 4)

This is the fourth in a short series of articles on Sage CRM Developer Best Practices. In the last article I discussed how project management and communication factors can influence overall project success. As part of that discussion I considered the importance of taking stock of the existing customer system before rushing in to attempt an upgrade or further customization project.

For the rest of the series I want to turn to considering the practical tips that can make life easier for team members. These are tips that will help achieve the initial success of a project and the long term ability to maintain a system and ensure customer satisfaction over the life time of a system.

Identifying practical tips is not as easy as listing out project pain points. I listed some of the project pain points in the very first article in the series. It is always easier to name the pain rather than to point out the solution. And after all if you know what best practice is, then the rather harsh question has to follow 'if you know what best practice is, then why are you not doing it?'.

There are some very easy tips to point you in the right direction. The first is to follow a project management methodology. The adoption of a formal project management methodology is a generic approach to projects and good project management techniques, whether classic waterfall or agile if applied appropriately and consistently would improve any project. This is not something unique and specific to the circumstances to working with Sage CRM.

Another easy tip is to be consistent in the way in which you write and organise your code. I am not going to be tempted into discussing the virtues of specific coding standards, and how C# should be written and how ASP files should be named and organised in the folders under custompages. Although specific conventions are very helpful and do allow code to be created that performs well and looks elegant, in the end it isn't the specific standard that is important but rather it is important that a common standard within a team is followed.

From a Sage CRM perspective it doesn't matter whether a team decides to use 'snake case' e.g. project_search_screen or 'camel case' e.g. projectSearchScreen just so long as the code convention adopted allows the person maintaining the code to have a better chance of understanding it some 3 years after it was originally written.

Below is my list of tips. These are all tips that I use when planning my projects and maintaining the components that are updated and re-released for each new version of Sage CRM. Essentially it is a list of ideas rather then a 'to do' list of actions that need to be followed. These tips are going to be useful not just for your Sage CRM projects but could be applied to your work with other Sage software just as well.

  • Proper preparation prevents poor performance
  • Think No Code and low Code
  • Think carefully about the API you will use
  • Avoid making direct manual changes to meta data and registry
  • Automate repetitive tasks
  • Create modules
  • Think about the person who will maintain your system
  • Comment your code
  • Carry out customization reviews
  • Be prepared to refactor at upgrade

My next article will look at what "Proper preparation prevents poor performance" means in the context of a Sage CRM implementation. It is an uncomfortable truth that Sage CRM project like any IT project can 'fail'. They can fail because of technical reasons, they can fail because of management reasons and they can fail because of commercial reasons. But whatever the reason for the failure the experience of failure sucks.

I am going to look at what 'cultural preparation' a team needs to make a head of a Sage CRM project. I am going to look at making sure that the commercial and management conditions are right before any hands touch the software.

Links to articles in series

  1. Introduction - Developer Best Practices (Part 1)
  2. Project Pain Points - Developer Best Practices (Part 2)
  3. Project management and communication factors - Developer Best Practices (Part 3)
  4. Practical Tips - Developer Best Practices (Part 4)
  5. Proper preparation - Developer Best Practices (Part 5)