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
- 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
- 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
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]
Make your code simple
- Simple to test
- Simple to maintain
- Simple to debug
- Simple to extend
Easy to Understand
reuse
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
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.
Consistency
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
- 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
- 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
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.
Consistency
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.
Plugins
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
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.
Summary
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.
Filed under: CRM 2011, CRM 2013, CRM 2015, Hosk CRM Dev, Hosk’s Microsoft Dynamic CRM Development

*This post is locked for comments