Why your CRM code and customizations should be simple


“Simplicity is the end result of long, hard work, not the starting point” – Frederick Maitland


“Simplicity is the Ultimate Sophistication” Leonardo da Vinci

In a previous blog post I wrote about complexity in code and customizations and the problems this can cause.

The problems with complex code and complex CRM Customizations

Complex code is hard to understand code because classes and methods do so many different things it’s impossible to understand how it works without stepping through the code to understand exactly what is going on. – Hosk

A quick recap
Here are some of the main culprits of complex code
  • Large methods – Monster methods
  • confusingly named classes, methods and variables
  • methods which do lots of things
  • not consistent
  • tight coupling
  • dependent code
  • poorly structured code
The problems associated with complex code
  • No Reuse
  • Complex Code is hard understand/read
  • Complex Code/customization is difficult to debug, maintain and extend
  • Creates complex bugs
  • Encourages more of the same

Code should be well structured, split up into logical classes and methods and the everything should have meaningful/logical names.  One part of good simple code is to make it readable, which makes it easy to understand when a developer is scanning the code looking for bugs or see where they should extend the code to add new functionality.

Methods should be in small and do one thing, this should ensure it takes out decoupling.

A lot of the work involved in keeping the code and customizations simple is managing the complexity of the CRM solution.

Writing code and customizations which seem simple is very challenging, it takes time spent on design, coding standards and will power.

Keeping the code simple is worth the effect because it’s so much easier to use and work with.  When you see great code it’s a thing of beauty, often surprisingly simple looking and will make you think you could easily write it yourself.

Keep it simple stupid

When you are writing code, keep in mind the KISS principle, below is a great summary from Wikipedia
The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided. The phrase has been associated with aircraft engineer Kelly Johnson (1910–1990).[3] The term “KISS principle” was in popular use by 1970.[4] Variations on the phrase include “keep it short and simple” and “keep it simple and straightforward”.[5][6]
Like most great advice in life and in coding, it can be broken down so it’s easy to understand but challenging to implement.
The KISS principle is described by the code it creates, simple and elegent.  When I  see an example of great code I am often amazed by the beauty and simplicity of it.  Code which adheres to the KISS principle is using small, tidy, precise, does one thing and does it well.

Make your code simple

if you do the above the code will be
  • Simple to test
  • Simple to maintain
  • Simple to debug
  • Simple to extend
The benefits of simple code is it’s simple to

Easy to Understand

If your code simple and the complexity removed then understanding the code is easier.


A good way to test if your code is simple, is to see if you could easily write a unit test for your code.  If you code is well written and the methods and classes are independent and have loose coupling.  Focused code is easier to write unit tests for because the methods do one thing and the tests only have to test the methods do the one thing.

Code which has loose coupling is very modular which means you can use it in other parts of the code or in other projects because the methods are not dependent on other methods in the project.

Making code for reuse sounds easy but I have found it’s unusual, which is why this quote has a ring of truth to it

code reusability in CRM projects is seen as often as bigfoot or the loch ness monster – Hosk
For more Hosk Quotes check out my Hosk Developer quotes page

No Extra Code

Simple code can be made to be extendable but it should not include any extra code which isn’t needed.  Simple code should go through refactoring so not only does it not contain any unneeded/unwanted code but the complexity is managed the quality is high.

Don’t add any extra functionality which might be used in the future.  The code should have been designed to be extendable.


There should be CRM standards document which all developers should have read and stick to.  Code consistency should also be considered when designing code solutions so the code is the same in different projects.

When code is structured differently when written by different developers it can make a project difficult to understand.

Easy to understand

Simple code should be easy to understand because it’s logically structured and consistent.  The code should be readable

What does this mean for a CRM developer

It’s easy to say “make your code simple” but how do we do that.   I would also focus on making your CRM customizations simple, including business rules, workflows

Front end

Looking at CRM from a user’s perspective, CRM should be as easy as possible to use.  CRM forms should be organised so a user can intuitively use the form.

An easy way to understand this is Good CRM design should not make users think

a few key points from the blog post which make CRM simple to use

  • Don’t make them think
  • Users are like sharks – they don’t stop moving and clicking
  • User like back buttons – it helps them to not get stuck
  • Users like searching
  • give them fewer options – filter options
The benefits of a simple user interface/CRM Form design
  • it’s easy to use
  • Users like using it
  • fewer barriers for using the system
  • Gets support on the customer end

Simple CODE

The key to simple code is the classes and methods focus on doing one thing.  As soon as classes and methods start doing more than one thing, they become hard to name, the code becomes coupled.  Code which does more than one thing becomes complex

Independent code

When trying to write simple code you should try to focus on writing independent code.  To write independent code means  classes and methods are focused and do one thing.

Easy to name variables and methods

When you write simple code you will find it’s easy to name classes, methods and variables and if you are struggling to name one of those its usually a side effect the code is trying to do more than one thing.

The great boon of writing simple code is it’s easy to understand because classes, methods and variables do what they say they do. Complex code is hard to understand code because classes and methods do so many different things it’s impossible to understand how it works without stepping through the code to understand exactly what is going on

Small Methods/functions which do one thing

You should write small methods, the reason for writing small methods is it will focus the methods, this makes the code reusable and easily tested.

Small simple methods are easy to understand, maintain, debug, extend.

reduce complexity

  • Classes and methods should do one thing
  • Independent code – the code isn’t coupled
  • Small focused methods

Don’t use lots of different customizations

There are lots of different types of customizations in CRM
  • Javascript
  • Business rules
  • workflow
  • plugins
  • Dialog
  • Console Application
  • Web Services

When I decide what type of customization to use in CRM for a particular problem, I usually go through this process

1.  What customization type can provide the functionality needed
2.  What customization type is best suited to provide the functionality
3.  What customizations already exist in this area and in the project

The process creates a list of possibles, which I whittle down to probables and then I need to match the probable solutions with the existing solutions in the project.

The reason for this is because if you have lots of overlapping customizations it makes maintaining, debugging and extending the CRM solution as a whole a lot more difficult.

I have experienced bugs where a plugin has a changed a value of a field, which then gets overwritten by a workflow.  The reason for this is plugins are usually syncronise and workflows are usually asyncronis.  In the bug I was investigating the workflow was running after the plugin.

I have also seen many questions from users on the CRM forums asking how Javascript and Business rules interacting.  Business rules do not trigger javascript on change events.  This makes understanding the customizations difficult because sometimes the Javascript onchange is triggered and sometimes it’s not.  It also means the CRM developer has to be aware business rules do not trigger Javascript on change events and make sure they create the customizations with this in mind.

To simplify it (which is what this blog post is all about)

Increase in types of customization = increased complexity

Your goal in creating a customization is not only to add the required functionality but good developers will concentrate on creating customizations which are simple because simple customizations are easy to understand, debug, maintain and enhance.


Customizations in a project should be consistent, even if it isn’t the best way of structuring the customization.  An example could be if a project only uses Linq queries and these Linq queries are in separate classes for each entity.  When someone else writes some plugin code they should use the same structure.


The most important part of writing a plugin is it does what it’s meant to do and provide the functionality needed.

Goal of a plugin

1.  To deliver the functionality required
2.  To produce quality code with the fewest bugs in
3.  To produce code which is easily maintained, debugged, extended
4.  To produce code which is easily understand

To create a plugin which has simple code it means you have you should not put it all in one big method directly in the plugin, yet how many times have you seen this in a CRM project?

Split up the code into classes which work logically e.g. entities or business logic/retrieves etc.

create small methods which do one thing.


Creating code which is as simple as possible really is breaking the code down into small independent parts which work together as a whole CRM solution.

Managing complexity is a never-ending task for a CRM developer, the better you do it the easier it is to work with the CRM project and code within it.

The main benefit of breaking the design and code into small simple parts is it’s easier to understand small simple parts and how they fit together.  This becomes more important when CRM developers work on multiple projects or have had worked on another project and come back.  Simple code will be easier and quicker to understand when you have lost the understanding of the business logic associated with the project.

Creating simple code and customizations looks easy (when you see the end product) but is extremely challenging to do.  Complexity of a CRM solution can quickly increase if the CRM developers are not focused on managing complexity and keeping the CRM solution as simple as possible.

18 thoughts on “Why your CRM code and customizations should be simple

  1. Markus Konrad February 27, 2015 / 2:39 pm

    This quote is missing: “Simplicity is prerequisite for reliability” – Dijkstra


    • Hosk February 27, 2015 / 2:41 pm

      very nice, excellent quote


  2. Jessub Kim November 30, 2015 / 9:35 pm

    In my projects, I have been using Inversion of Control and Repository pattern for simplifying codes like plugin. It achieves pretty much all that is said in this article


    • Hosk November 30, 2015 / 10:17 pm

      Sounds awesome. I had to look up the Repository pattern, it sounds good.


  3. Lakshmi February 1, 2016 / 6:47 pm

    Well articulated article.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s