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.


CRM Developers don’t know what they don’t know!

There must be a happy medium somewhere between being totally informed and blissfully unaware.

Doug Larson


I read a fantastic article today on boingboing with the title

Why we are unaware that we lack the skill to tell how unskilled and unaware we are

It starts with a great quote

Each one of us has a relationship with our own ignorance, a dishonest, complicated relationship, and that dishonesty keeps us sane, happy, and willing to get out of bed in the morning. By David McRaney


The article mentions Nescience, so I thought I would use it but first lets understand what it means



Lack of knowledge or awareness; ignorance.

How is this relevant to CRM Developers

When you start out as a Developer and CRM developer you don’t know much and the main problem is

You don’t know what you don’t know


No I didn’t type that line twice or incorrectly, what I’m trying to say is junior CRM developers/ people starting CRM development have a lot to learn.

  • Knowledge of all CRM customization techniques
  • CRM Development Best Practices
  • Writing well structured code
  • Using the right Customization for the right job
  • CRM Infrastructure (e.g. Servers and components)
  • Testing and debugging
  • Converting customer requirements into solutions
  • Learning new CRM functionality
  • Lots and lots of other things

Getting it working

The first stage of improving is getting hands on experience with CRM development/customization.  At the initial stage this is where you know the least and don’t know enough to realise how much you have to learn.

The initial steps are getting practical examples to work e.g. Getting your hands dirty by creating entities, fields, views.

  • Creating new entities/fields/views/relationships and other GUI customizations
  • Creating workflows/business rules
  • Writing plugins/custom workflows
  • Integrating WCF webservices with CRM
  • Writing CRM Applications

This article about Knowing and Not Knowing is a great article which has a great visual and quote

The important realisation is understanding the areas which you have to learn and making a plan to learn about them

The key stage is moving from

Don’t know what you don’t know


Know that you don’t know


Doing it right

The CRM developer will at some point have got experience doing most of the different CRM customization types and will be comfortable with the process of creating them all.

The good CRM developers will start to move ahead of the average/bad CRM developers because they will start to produce good quality customizations and write plugins/custom workflows/WCF which are well structured/readable.  These customizations are easy to read/understand and easier to maintain and modify

Good CRM developers have a detailed knowledge of how CRM customizations work and the underlying CRM infrastructure.


How to learn what you don’t know

I started off this post by mentioning most people lack the skill to tell how unskilled and unaware they are

Sometimes this is because of ignorance and you simply don’t know what you don’t know.

There are actions you can take to learn about CRM Development


Read blogs

great examples of good CRM custmoizationswritten by great CRM Developers.  Good blog posts not only show you new functionality but also teach you the logic behind it and throw in a few best practices as well.

Example of new functionality you haven’t used yet.

Read Books

I recently wrote a blog about some great books for developers

Recommended Books for Developers

Books offer something different from blogs and articles.  They are focused and in depth look at a subject.


Correct Attitude

At some point the good CRM developer realizes he has a whole bunch of stuff he should learn about, but the list is big and the only way to tackle it is to constantly keep learning and improving on a daily basis.

Learning to be a better CRM Developer is like eating an elephant, one bite a time.

Don’t be afraid to question what you don’t understand, Ask fellow CRM developers at work or raise questions on forums.


CRM Customizations – Doing

Writing customizations will help you learn and improve.  Experience is a key for CRM developer, you will get to a level where you are comfortable with the process of creating CRM customizations.

Once you can easily create customizations the next stage is creating great customizations.  Customizations which will be easy to understand, maintain, extend and debug.


Learn from your colleagues – Peer Reviews

You can talk to fellow CRM developers about CRM development, the best way to do things, tips on creating customizations, mistakes to avoid.

Having your code peer reviewed is a great way to get feedback on your customizations


Learn from your mistakes

You will create bugs, you will choose customizations which don’t work because they are technically not correct.  You will have peer reviews where your code gets criticized.

Don’t take peer reviews personally, but learn from them, improve and don’t make the same mistakes in the future.  I personally find mistakes stick more vividly in the memory


Learn from previous coding – the good and the bad

You will have to work on projects written by other CRM developers.  Use this as an opportunity to find out the good customizations and the bad customizations.  Focus on why code is good and why the code is bad.

You take the good things and remove the bad things from your own customizations/coding.

Learn in public

A great way to learn is by writing blog posts, answering forum questions and learning with feedback and interaction from other CRM developers.

It’s even more fun learning with other people


known unknowns

I will finish with this classic quote from Donald Rumsfeld

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.

Donald Rumsfeld