Dynamic CRM Salary survey 2016

 

Only in our dreams are we free. The rest of the time we need wages.

Terry Pratchett

 

Dynamics recruiter Nigel Frank International annual Microsoft Dynamics salary survey is available and is an interesting read, you can Download Salary Survey Report

The Dynamics survey is made from 18704 professionals in 131 countries and doesn’t just focus on salary but other areas

• geography
• wages
• working hours
• gender
• certifications
• bench time
• reason for changing jobs
• bonuses and benefits

Nigel Frank suggest you find out:

• How much you should be earning
• How your salary compares to others in similar roles
• Insights into global bonuses and benefits
• Movement between End User and Partner
• Insights into the motivations for changing jobs and employers
• Key aspects of job satisfaction

Why you should care about average wages?

Average salary surveys are a broad guide,roles and responsibilities can’t always be grouped.  The regions in salary surveys can be vast, in the UK it groups the Midlands and East Anglia when these areas are over 100 miles apart (it’s big in the UK overseas readers).  Salary surveys have people who have just started in a role and someone who has been in that role for many years.

Working isn’t all about money, well until you find someone else in the company is getting paid more for doing the same job!

There is value to salary surveys, it gives you an opportunity to compare your current wage with the average, it gives you an estimate of what you could earn for your current role or a different role.

Its perceived wisdom you will get bigger pay rise if you move companies because companies give you a percentage pay rise of around 3 to 5 percent.  When you move companies you might get a double-digit pay rise when the company pays you for the experience.

With the increased effectiveness of recruitment consultants thanks to LinkedIn, perhaps Microsoft Dynamic partners should pay more attention to the average wages because its likely Microsoft Dynamics professionals will receive job offers via LinkedIn.  If companies aren’t paying the average wage then these employees could be tempted away.

I’m often curious of the cost of replacing an employee, do companies take into account

• business knowledge
• project knowledge
• relationships
• internal process and procedure knowledge

hiring a new person brings

• Recruitment costs (time)
• Recruitment agencies (if you can’t use your network)
• risk of hiring unsuitable person (skills, personality/culture clash)

There are lots of potential pluses if you hire the right person, they bring in fresh ideas, different perspectives, energy and enthusiasm.

It’s easy for Dynamics professionals to leave, this highlights how important managing your Dynamics professionals is and ensuring they are content.  Dynamics CRM is a people business, in most instances the company is selling the skills, knowledge and experience of their CRM professional rather than a product.

Average Salary is a tool

Knowing the average wage is a useful bargaining tool to take into your review (as long as its more than your current wage).  It gives an anchor to the discussion and offers an impartial view of an average wage in the industry

if you are thinking moving jobs, it be used to see if the role is paying the going rate and not just more than your current wage.

Interesting facts in the survey

The survey was probably limited by the need for English speakers but 27.6% of the responders were from United States with 10 percent from England.

  

 

42% are certified

35.7% experience a pay rise post certification

It shows the benefit of passing Dynamics certifications with a 3rd receiving a pay rise, surely it’s worth a couple of months revising for a certification to get a pay rise and increase you knowledge of Dynamics CRM.

34% plan to leave their current job within 12 months (if you listen carefully you can hear the recruitment consultants cheering)

28% sat on the bench for more than 1.5 days a week in 2015.

34.3% said the reason to move job was lack of Leadership & vision

Sales Salary Figures UK

Who do you work for?

It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages.

Henry Ford

 

The question of who you work for? is different to who pays your wages.  People stopped working for one company for their entire career.  Microsoft Dynamics CRM professionals are likely to move many times in their career, so the person you work for is yourself.

You should make sure you are managing your own career

• Getting useful/desirable experience
• learning new skills
• Getting certified
• Making sure your career is progressing

If you haven’t set yourself a career goal or next step in your career, its unlikely you are working towards it efficiently.  When you know your dream job/role, you can work backwards from it, calculating what the skills, experience, network and knowledge you need for the job.

If You Don’t Design Your Career, Someone Else Will

Purpose

“No one is really going to help you or give you direction. In fact, the odds are against you.”
― Robert Greene, Mastery 

Everyone wants to get paid and lots of money is great but it won’t help you enjoy your work.  People spend at least 7.5 hours a day at work,  its important you enjoy work and feel you are contributing.

Many articles I have written on CRM development – Hosk‘s CRM Developer articles involve people having high standards and passion for the role as CRM Developer (CRM Developers need Passion), if you don’t enjoy something you won’t push yourself to learn and improve, holding back your career development.

I have asked myself the question – Why do people stay in boring jobs.  Sometimes the answer is money because they can’t earn as much money doing something else, this leads to long work days and people counting down the days to retirement.

 “The purpose of life is not to be happy. It is to be useful, to be honorable, to be compassionate, to have it make some difference that you have lived and lived well.” ― Ralph Waldo Emerson

Advertisement

Dynamics Connector is being discontinued, What does it mean?

It does not matter how slowly you go as long as you do not stop.

Confucius

I read this article Connector for Microsoft Dynamics support for Microsoft Dynamics CRM beyond Dynamics CRM version 2016, it has this quote

Dynamics CRM version 2016 will be the last major version of Dynamics CRM to be supported by Connector.

The latest version can be found here

http://blogs.msdn.com/b/dynamicsconnector/archive/2014/12/04/connector-for-microsoft-dynamics-v3-cu-4-released.aspx

What does the Dynamics connector do?

The Dynamics connector connects Microsoft Dynamics CRM and other Microsoft Dynamics products (NAV, AX, GP).  It‘s a product created by Microsoft and given away free to Microsoft partners.

The Dynamics Connector is like a free version of Scribe but harder to use and with less functionality (but its free).

I used the Dynamics connector for a while, the biggest obstacle was the lack of information and blog posts written about the connector.  As soon as anything went wrong it was almost impossible to get help to resolve the problem.

You can my blog posts on the Dynamics Connector, they are primarily focused on fixing problems

https://crmbusiness.wordpress.com/category/dynamic-connector/

Who uses it

Many Microsoft Dynamics partners use the Dynamics connector, it‘s useful tool to synchronise data between CRM and other dynamics products.

The biggest advantage it has is it‘s free, so can reduce the cost of the project, which is useful for small projects where money is tight.  When using the connector you often end up spending pltenty of time getting the connector to work, any money you save on not buying Scribe licences will is used development and setting up the Dynamics connector, particularly if you need to synchronize custom entities.

What does discontinuing mean

It‘s seems a strange decision to drop support because you would think Microsoft would want to integrate Microsoft Dynamics CRM with other Dynamics products.

The question I’m asking is – why wouldn’t they continue to support it? because to synchronise you need licences to two seperate Microsoft Dynamics products, surely something Microsoft would encourage.

In Dynamics AX they are bringing in functionality to Synchronize AX with Dynamics CRM.  The functionality is not ready yet but as always it’s imminent.  The discontation of the Dynamics Connector and new functionality inside Dynamics products is perhaps the model Microsoft are moving towards..

The communication between Microsoft and the Dynamics community is not open, so we are left guessing for the time being.

If Bob Paisley managed a CRM team

“The greatest leader is not necessarily the one who does the greatest things. He is the one that gets the people to do the greatest things.”

Ronald Reagan

People are the most expensive and valuable asset of Microsoft Dynamics CRM re-sellers, a great leader can make the difference between a successful company and an average company.  Great leadership creates a vision of the future and engage and inspire individuals to achieve the vision.

People are to Microsoft Dynamics CRM re-sellers because most sell people not products.  Its the CRM professionals who deliver projects, capture requirements, design solutions, document, interact with user.

People are an important resource for Microsoft Dynamics CRM reseller,  a leader is needed to direct them, motivate them and manage them.

I read a great article on Bob Paisley and like most things it brings my thoughts back to how the lessons and insights show to Microsoft Dynamics CRM and working in IT.

BOB PAISLEY: THE GENTLE MAN WHO COULDN’T STOP WINNING

Bob Paisley was one of the most successful managers ever in England, he was assistant manager at Liverpool between 1959-1974 and manager from 1974-1983.  Whilst managing Liverpool winning on average on 2.1 trophies per season, winning 19 major trophies in 9 years.

The article raises many great points about leadership and like most things I read, I apply the information to the Microsoft Dynamics CRM industry.

Leadership

The article discusses leadership.

Good football teams require direction and leadership. The captain functions as the on-field general, rallying the troops in the heat of competition. The manager is really the captain steering the ship, navigating the crew through football’s tempests save for 90 minute bouts where he must lead from the other side of the chalked white lines.

Every team/organisation needs a leader to create a future, outline the direction of the company.  Leaders create and develop other great leaders in an organisation, these are the captains.  Management set the culture of the company and the values its employees should show.

The skill of simplifying a companies strategy can motivate a team to deliver the strategy, a fuzzy strategy or direction reduces commitment and effort of a team.

A CEO/Head of CRM practice and upper management who steer the ship, below them you are the captains and leaders, such as solution architects, senior consultants.  To deliver multiple projects you need a strong team,  the senior members offer guidance and direction to the junior members, setting standards, avoiding problems, helping them grow and improve and deliver projects on time.

Being listened to not just being heard

“The man exuded class and calm and once spoke of the importance of speaking softly so people actually make the effort to listen. Paisley knew man-management was about being listened to over being heard.”

 

Listening is a key skill needed by CRM professionals.  A boss once said CRM developers must keep listening until the users stop talking, CRM developers should listen more than they talk. When a CRM developer hears requirements they formulate a solution.  Creating the solution too early means they switch off listening to the rest of the requirements.

The boot room

Liverpool in the time of Paisley used the clubs boot room as a place to discuss strategy, the game, players, everything and anything.

On Sunday mornings we’d go in and talk about the Saturday game. There were differing opinions and disagreements and everyone put their oar in. But it was all done in the right manner. We liked everyone to air their views and you probably got a more wide-ranging discussion in the Boot room than you would in the boardroom. But nothing spilled out of there. What went on was within these four walls. There was a certain mystique about the place, which I also believe there should be about the dressing room. What’s said in there should, by and large, be private too.”

 

Liverpool had the boot room but for many CRM professionals going to work, having a coffee, lunchtime is their virtual boot room.  Talking and sharing ideas on CRM with your colleagues is a great way to learn about CRM and it’s practical implementation.

Experience is valuable with Microsoft Dynamics CRM, many key lessons are learnt from trying, failing and find problems with solutions.  The limitations of functionality is fundamental in the choice of customization, experienced CRM developers/architects choose the right customization for a requirement.

The ideas, thoughts and experiences of your work colleagues is one of the most potent sources of learning available to many CRM professionals, be sure to use it.

Team game

Bob Paisley wasn’t kidding when he said, “It’s not about the long ball or the short ball, its about the right ball.” In football, there’s a phrase good coaches use with young players: ‘make it easy for the other man to play the game’. Liverpool players played for one another through selfless, supporting and fluid football.

When working in any team you need to view your actions in the long term

• gains for individuals and the team
• documenting procedures
• creating best practices
• sharing information/code/documents.
• Creating and maintaining relationships with other team members
• maintaining development environments

Some tasks need to be done

• Production deployments (often out of hours)
• help desk duties
• Time sheets

Supporting each other and the team is required to work, these two articles focus on working as a team.

• Never leave a developer stranded
• bad code is like a virus

The articles focus on keeping quality and standards high as individuals and as a team.  The actions of individuals effect the team physically and mentally, individuals working hard and to high standards will influence their peers into doing the same, individuals can inspire their team mates.

 Alan Hansen surmised Paisley insatiable appetite for success by saying: “If there was one word that Paisley hated, it was the ‘C’ word: ’Complacency’.”

We must improve, look for opportunities, keep learning.  Microsoft Dynamics CRM industry is evolving, adding new version, new related services, the speed of change is highlighted in this article – The rise of Microsoft Dynamics CRM 

continuous improvement is key to a successful career Why CRM Developers should always start with the CRM SDK, I have this quote

My aim each day is to know more about CRM development when I leave work than when I started it.

If you want to learn more about Bob read this book Paisley: Smile On Me And Guide My Hand

I will leave you with some quotes from the great man

 

I can let the team do the talking for me. Bob Paisley

 I love the city and the people here. I’ve been with them for many years and I fought alongside them. Bob Paisley

“If you’re in the penalty area and don’t know what to do with the ball, put it in the net and we’ll discuss the options later.”

“Mind you, I’ve been here during the bad times too – one year we came second.”

Oi Hosk, Why the lack of blog posts

Be grateful for what you have and stop complaining – it bores everybody else, does you no good, and doesn’t solve any problems.

Zig Ziglar

 

Some blog readers have complained (in a nice way) about the lack of blog posts from the Hosk.

One person said, why don’t you write a blog about not writing blog posts, which would help fix the lack of blog posts.

My first reaction was to say

• I have been busy
• I haven’t had time
• I was ill

Often my instinctive reaction to a question is often defensive and a justification to myself.

Defensive answers are not useful because they don’t tackle the true cause deflect the question from being answered.

The truth is, I haven’t prioritised writing my Hosk CRM blog.  If you really want to do something you make time to do it.  

Quality not Quantity

When writing the blog post Tips on how to become a CRM MVP from CRM MVP’S, which summarises CRM MVP Q&A

I have been trying to increase the quality of posts, by spending more time constructing blog posts (this one excluded) by

• Make notes on the subject
• Design the subheadings
• Write
• Edit (about time many readers will be saying)

The goal of writing better quality posts is to create posts with more Hosk thoughts and insights (I do have a page of quotes!).  Do create posts with deeper insights you need to spend more time thinking about a subject.

The Hosk blog grows

I have been blogging for 5 years and have written over 1000 posts on CRM.  The early posts were quiet basic often involving linking to other good blog posts.  In the early blog days what I lacked in skill and original thought I made up for in number of posts.

The early blog posts I viewed the blog as a tool to help share great content on CRM 2011.

As my knowledge and expertease in Microsoft Dynamics CRM grew so has the length, detail and insight in my blog posts.

The Hosk CRM blog has grown in numbers over and this year has already had 50000 more views than last year and for the first time I have clocked up over 500000 views in a year.

CRM MVP – Failed

An initial goal of the blog was to help me achieve CRM MVP status, I learnt like many others, it’s extremely difficult to become a CRM MVP.

A general rule of thumb with regards to becoming a CRM MVP (which I have been told many times)

Those who really want to become a CRM MVP, seldom do. 

 

After 10 nominations (2 and half years)  I believe you can’t become a CRM MVP by just writing a blog.   If you think who are the thought leaders in the Microsoft Dynamics CRM community, the currently nominated CRM MVP’s offer great advice, insights and best practices for Microsoft Dynamics CRM.

My motivation has changed to focus on creating quality blog posts.  A goal which I stated in New Year Hosk CRM Resolutions

Everyone should write a CRM blog

I believe everyone should write a CRM blog, for these reasons

• To help others in the CRM community
• To learn more about CRM
• Social media content is your professional brand
• A place to store your CRM knowledge

Writing the Hosk Dynamics CRM blog has been great and I have referred to it as my online CRM Brain in this blog post CRM 2015 – How to diagnose plugin errors.  If I have a CRM error, I usually search the Hosk CRM blog for answers (or google which usually takes me to the Hosk CRM blog).

Writing the blog has created a Hosk CRM brand and most CRM developers I meet have read my blog, which is cool.  It’s useful when going for interviews and in one situation someone went was asking me questions featured on my blog

Are CRM Developers are afraid of creating classes?

I have seen lots of CRM code and my initial thoughts are CRM developers don’t seem to create many classes or spend much time designing their code.  In this blog post I will discuss the effects of not creating classes and explain the benefits of classes and abstractions.

Are CRM Developers afraid of creating classes?

The problem seems to be self reinforcing.  Previous CRM projects contain few classes and most of the code exists in the plugin, this sets an unspoken standard which encourages developers to not create classes.

This is a mixture of a safety in numbers/wisdom of crowds approach, it could be seen as consistency and a standard approach to CRM development is good.  Consistency in CRM development helps developers maintain, debug and extend CRM projects.

In the case of putting code in the plugin and not creating classes I think it’s bad practise and every plugin you add creates more technical debt for the CRM project and CRM projects quickly resemble legacy projects with complex CRM customizations

The end result is complex code doing lots of things and impossible to reuse and extremely difficult to work with (maintain, debug, read, etc).

To not use classes and put all or the bulk of the code in the plugin class

• makes it impossible to reuse code
• create complex code which does many things
• creates duplicate code
• create code which is hard to understand
• Code is very difficult to test

CRM plugins are often small, focused code but to not create classes or abstractions is to create a code base technical debt.  This debt is paid back when CRM developers take longer to interact with the code in the future.

Plugins with few or no classes results in each developer creating new code every time because it’s impossible to reuse any of the code in the other plugins.

If CRM developers are not creating classes they are creating legacy code and plugins contain monster methods – Hosk

Boy Scout rule

The focus when creating code should be to keep the quality high, test everything and keep code as simple as possible.

When you create plugins or every time you make a code change you make you should leave the code in better state than you found it.  Why you should write code and customizations like a boy scout

Quality of code is fundamental to the long term success of a CRM project and as soon as you lower your coding standards and let in bad code, it will soon spread Bad code is like a virus, don’t get infected

What is the role of Classes in programming

I advocate no code logic should be added to the plugin class except a call to a class passing in the entity, IOrganisationService, ITracing.

Putting logic in a plugin creates complex code, which is difficult to unit test but there are other reasons to create classes which are listed below

No Duplicate code

Duplicate code is one of the worst code smells and it has multiple bad side effects

• More code = more potential bugs
• duplicate code = bug fixing can result in multiple fixes
• bug fix one set = miss out changing duplicate code, which one is right?

When ever you find duplicate code or are about to create duplicate code, take the opportunity to find the common behaviour and abstract it into a class.  This will enable you to reuse this single piece of code in many places.

Using classes and functions is the primary weapon against duplicate code because you are logically sorting code in logical class/method, which will allow developers to easily find and use it.

Modelling real world and abstract ideas

Classes allow you to model real world objects (account) and abstract concepts (printing, validating).  The benefit is you can split up the code into logical abstractions which give clarity to the intent of the code.

CRM out of the box models plenty of real world objects

• Accounts
• Contacts
• Opportunities
• Phone Calls

Abstract classes

• Security role
• Solution
• Behaviours

You can create classes to model behaviours, this could be things like validating, printing, logging.  These behaviours can be use in composition and used in multiple classes.  The benefit of modelling behaviours is reuse

• Create abstract objects
• Create real world objects

Reduce complexity

Classes reduce complexity by splitting code into abstract or logical sections.  The term abstract can be confusing, instead replace it with logical groups.  Splitting code into logical groups organises the code into smaller/reusable sections.

Breaking the code into classes creates cohesive code and reducing dependencies between classes.

Creating well named classes with well named methods reduces complexity and makes the code using those methods and classes easier to read/understand.

Creating classes and methods allows you to create descriptive methods, e.g. call the a print method is easier to understand than reading all the lines of code needed to print.  At a high level you might not need to know all the details of printing.

Manage the effect of change

Classes help reduce the effects of change by removing dependencies between classes (assuming the classes are well designed).  Using abstract classes can remove the effects of change on the code using the abstract classes.

Well designed code can make it easy to add new types by encapsulating what varies and programming to interfaces.  Adding a new type should not effect the other types or the code using the abstract class.

Managing the effects of change can reduce dependences and stop changes in code unexpectedly breaking other parts of the system.  You could rename this to limiting the effects of change by reducing the ripple effect change has on badly designed code.

Information hiding

Read my blog post Good coding practices – Information hiding

hold data instead of lots of parameters

You can structure classes to hold the data instead of passing lots of variables between methods.  This makes the code easier to understand and interact with.

Create reusable code

Many CRM projects I have worked on/inspected have had almost no code reuse partly due to the lack of classes created.  Part of the reason is attitude, CRM developers don’t view creating reusable code as a priority.

CRM organised internal entities to make it easier to understand how it works.  If we take security roles as an example.

The security role entity contains the main privileges which have a value of TRUE or FALSE and one of the four access levels Global, Business Child, Business unit, user.

Every time we add a new entity, we can set privileges for Create, Read, Write, Delete, Append, Append To, Assign, Share.

Whilst thinking about the example above I would except Privilege to be a separate class but we can see understanding the data in this structure is easier.

The benefits of designing classes 

The clean coder has a good change on classes which talks about change isolating change

Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which
represent concepts only. A client class depending upon concrete details is at risk when those details change. We can introduce interfaces and abstract classes to help isolate the impact of those details.

Abstraction and modularity allows developers to work on separate parts of a system without having a detailed knowledge of the whole system.

Plugins allow developers to create new plugins without affecting other plugins.  The crm dev needs to check there are no other plugins being triggered on the same entity.  Good design of the code is based on on the plugin interface and not the concrete class e.g. your plugin.

Well designed classes have many benefits

• The code is created from many simple classes and methods
• The code is easy to unit test
• Well designed classes have minimal dependencies
• Well designed classes should be able to be reused
• Classes and method can make the code easier to understand
• Good abstractions can be used in different projects

Coding to an interface

The benefits of coding to an interface and using classes behind the interface is you limit the effects of change behind the interface.

You can add new types behind the interface without affecting any of the code which uses the interface.

A quick example is routing records to different users or teams, for this you could create an interface called Route and then concrete classes will contain the routing details and default value of the users/teams.

Route – Interface

• RouteToTeam
  • RouteToDefaultTeam
  • RouteToSalesTeam
  • RouteToMarketingTeam
• RouteToUser
  • RouteToSalesManager
  • RouteToCaseManager

The benefits of coding to an interface and using classes

1. Any code using the Route interface will be unaware of what specific type of route they are using.
2. The code calling the interface has no knowledge of what objects, variables are used to route, it calls the Route interface methods
3. Its easy to add new Routes which will involve changing minimal amount of code
4. The code using the Interface is decoupled from the concrete classes
5. The effects of change are restrained by the interface
6. Easy to test
7. Selecting the type can be done dynamically at runtime

Dependency Inversion Principle (DIP)

Reading about the Dependency Inversion Principle (DIP) helped me understand abstractions and the benefits of using them.  To remind you what DIP is

Depend on abstractions, not on concretions.

Wiki adds two more points to help understand

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

I highly recommend you read Uncle Bobs article The Dependency Inversion Principle, where he explains it a lot better than me.

This article DIP in the Wild has a good example of using DIP which helps understand  the concept and it’s usage in developer life.

Abstract ideas can be tricky to understand, to make this easier to understand think of black boxes.

Black boxes are code which works but the user of the black box doesn’t know how the code works inside the black box.  The internal code can change but the consumers of the black box wouldn’t know.

Change has been isolated inside the black box, Interfaces and abstract classes operate as black boxes hiding the change behind them.   Any code which interacts with an interface/abstract class won’t need to change if the internal workings behind the interfaces/abstract classes change.

A good example is using the CRM SDK to interact with the CRM database.  Microsoft can change how the internal workings of the CRM SDK change and can change the CRM database structure (in CRM 2015 they removed CRM database extension table).

Microsoft removed a whole table but CRM developers who used the SDK wouldn’t have noticed any difference (I didn’t notice) but those who developed code/reports directly against the CRM table would suddenly find their code/reports no longer worked when they upgraded to CRM 2015.

The next blog in the series is how to find Classes

CRM 2013 – Javascript null setting oddity

I had an odd error where I was trying to null a lookup field in Javascript in CRM 2013 Service SP1.

When the user changed a lookup field, I wanted to blank out a few fields to make them select those fields again.  The fields being nulled were dependant on selection of the first lookup field and the options and values they could pick changed.

It’s good practise to reduce the number of choices users have by filtering out values in option sets and lookups, hiding/showing fields.  This makes the forms more cohesive, less noise for the end users.  Read more about CRM Form design in the article below

Good CRM design should not make users think

The initial code was in a function and looked like this

        if (Xrm.Page.getAttribute("field1").getValue() != null) {
            Xrm.Page.getAttribute("field1").setValue(null);
        }


        if (Xrm.Page.getAttribute("field2").getValue() != null) {
            Xrm.Page.getAttribute("field2").setValue(null);
        }
        

Oddly field1 was correctly set to null but field2 refused to be set to null.

To add to the annoyance of not setting the field to null, the not nulling triggered the OnChange event for the lookup which set other values on the previous not nullable value!!!

This made me angry

Stepping through

When bug fixing the goal is understand exactly what is happening, once you understand what is happening it might be possible to work out why or work around it.  There is a big difference between

• Knowing what is happening
• Your assumptions about what is happening

Assumptions are dangerous because they can easily be wrong.  When bug fixing don’t assume anything and prove everything.  I have wasted plenty of time with assumptions and investigating the wrong section of code.

I started debugging and stepped through the setting the values to null.  The handy part of debugging JavaScript is the console allows you to integrate the values.

The values on the GUI looked like fields1 and fields2 were both not being set to null.

I debugged and stepped through the code, field2 wasn’t being set to null but the OnChange event was running for field2 which was setting field1 and field2 to the values based on the previous field2 value.

One change at a time

One of the golden rules when debugging a problem is to change one thing at a time, monitor the effects of the change.  This rule is particularly inportant if the change is a configuration change which will be changed on multiple environments (DEV, TEST, PREPROD, PROD).

When changing values or code, making a solitary change will show you the effects of the one change.  If you change 5 things at once which resolves the problem, you don’t know what change has fixed the problem.  In the multiple change scenario you would either need to go back and change one variable at a time or make all the changes in all the environments.

When making changes to code/config it’s good practise to minimise the changes, which minimises the potential unknown effects of these changes and reduces bugs coming from these changes less likely.

I tried

• removing field1 change
• swapping the order, changing field2 before field1
• double checking javascript
• Asking fellow CRM developers

Asking fellow CRM developers did bring a few mumbles of maybe having seen something like it before but no one could remember what is was or what they did (if only they wrote a blog post about it!!)

None of the other changes did much.

To the Internet

 

Searching the internet didn’t bring up anything directly relevant (how often does that happen!), it did lead me to this page

Javascript, onChange events no longer work on an empty field

This wasn’t the problem I was experiencing

I just noticed that if you have a form field that triggers a Javascript function on the onChange event it no longer triggers the function if you clear the field, but ONLY when you change the field data. For instance; if you have a Name field populated with a name, and you remove the name – the function isn’t triggered. It’s left empty. You have to change the text inside the field.

 

The problem being talked about here is setting required fields to null didn’t trigger the onchange.  I had this reverse of this problem I was setting field2 to null, it wasn’t setting but triggering the OnChange, which means Microsoft fixed the problem report (the forum posts were Feb 2014).

The forum post go me thinking, lets change the field requirements and see what happens.

Setting field requirements using Javascript

Fields have three levels of requirements

• none
• required
• recommended

For some reason accessing these programmatically seems quite different from setting/adjusting them using the GUI.  Looking at the list what is the point of recommended, it should be required or none.  Why you would want to change a field to have a requirement level of recommend?

The code is string based, which seems a little odd and prone to syntax errors.  To find all the Javascript methods use this page on the CRM SDK

Xrm.Page.data.entity attribute (client-side reference)

Here is an example using the trusty field2

• Xrm.Page.data.entity.attributes.get(“field2”).setRequiredLevel(“none”);
• Xrm.Page.data.entity.attributes.get(“field2”).setRequiredLevel(“required”);
• Xrm.Page.data.entity.attributes.get(“field2”).setRequiredLevel(“recommended”);

I changed my code to set the required level to none, set field2 to null and then reset the required level to required.

//I had to set required level to none because assign null wasn't working, might be fixed in future roll ups
	if (Xrm.Page.getAttribute("field1").getValue() != null) {
            Xrm.Page.getAttribute("field1").setValue(null);
        }

        Xrm.Page.data.entity.attributes.get("field2").setRequiredLevel("none");
        if (Xrm.Page.getAttribute("field2").getValue() != null) {
            Xrm.Page.getAttribute("field2").setValue(null);
        }
        Xrm.Page.data.entity.attributes.get("field2").setRequiredLevel("required");

Leave a comment

If you have written some unusual code as a work round for a limitation in design or a known bug, it’s good practise to leave a comment explaining to other developers (and maybe your future self) why you have put the code.

Reasons why you should comment unusual code

• A developer could easily delete the code without realising what is meant to do
• It could be confusing for other developers to read and understand
• A rollup/service patch might fix the code and it could be safely removed
• The developer reading the code might know the solution to this problem
• It’s good practise

Are your CRM plugins creating technical debt?

The image above is from the article DEALING WITH TECHNICAL DEBT, which I recommend you read, right after reading this one 🙂

The common method of creating plugins in the CRM projects I have worked on, is putting all/most of the code directly in the plugin class, this creates code which is

• Complex code
• Hard to read
• No code reuse
• Difficult to debug
• Writing unit tests is hard so most CRM developers don’t bother

This method of developing plugins creates technical debt to the CRM project instantly and pushes the code towards legacy status and creates spaghetti code

The motivation for writing this blog post is a most CRM projects don’t have enough classes\abstractions in them and the code written is not adhering to good object orientated design principles.

The lack of design and structure in CRM plugins I believe is one of major reasons there is little code reuse in projects and between projects.

I have experienced CRM projects where multiple developers have independently written the same code, not only creating duplicate code (and more code to maintain) but each developer had to spend time writing the code.

CRM developers seem to have an aversion to creating classes and finding abstractions in their code.  A common occurrence in CRM code is the creation of the Plugin Monster method

The plugin monster method is a CRM plugin which has all of the logic, which can be many lines of code.

Technical Debt

Creating CRM plugins without using classes creates a project with lots of technical debt.  The amount of technical debt is increased with the creation of every new plugin.

Creating plugins with classes or using OO principles will lead to CRM project code reaching a legacy level almost before the project is released to the customer.

This type of coding doesn’t adhere to the S.O.L.I.D principles.  This article gives a quick summary of the S.O.L.I.D principles

Most developers (hopefully) have heard of  S.O.L.I.D. principles and the principles of Object Orientated Design.  The best place to start is with Uncle Bob’s Principles of OOD

Below is the Uncle Bob’s list of the S.O.L.I.D. principles with links to his articles on the subject.  The first five principles are focused on class design

SRP	The Single Responsibility Principle	A class should have one, and only one, reason to change.
OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.
DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.

Many developers have heard of the SOLID principles, fewer developers understand the principles and even fewer put them into practice when creating their plugin/custom workflow code.

You might think CRM development doesn’t need to implement OO principles because plugins are small focused pieces of code.  This view is has resulted in plugin code consiting of poorly written, complex code and explains the lack of reusable code generated by CRM projects.

Code being re-used in CRM projects is seen as often as big foot – Hosk

Common attributes of CRM projects (in my experience)

• The number of classes is minimal in CRM projects
• Classes and methods doing more than one thing
• Most projects have no unit testing and the code would be hard to test due to complexity
• The S.O.L.I.D principles rarely  implemented
• Almost no code reuse, even in the same project between plugins

Projects with the characteristics above have little/no code reuse and contain an abundance of technical debt which makes supporting them difficult.  All interaction with the code will take longer and longer.

Code Interaction is

• reading/understanding
• debugging
• extending

Why does poor plugin code get created

I have seen many many many plugins written where all the code is included in the plugin.  This blog is about poor class design but putting all the code in a plugin is not even designing a class.

Putting the code in the plugin and creating one big method is poor coding and results in

confusing complex code which is hard to understand
Very hard to unit test a plugin
zero code reuse

Complex plugin code with poorly designed code leads to these problems

• debugging is difficult and takes longer
• bug fixing is difficult and takes longer
• No unit tests means refactoring is difficult and often avoided

The bottom line is the project which becomes a legacy project and developers try to interact, change and extend the code as little as possible.

Explanations for poor plugin code

Below I will discuss the reasons why I believe poor code gets created most of the poor code could be avoided with code reviews.

Junior developers

Some plugin code is written by junior developers who didn’t apply the principles for designing and structuring classes and methods.   The blame should not be placed on the junior developer, the reason why this code is still in the project is because their is lack of code reviews in CRM development.   A code review would have picked up the poor code and the code would have been rewritten with some guiding advice on the areas to improve.

Poorly skilled developers

There are some developers who don’t enjoy being a developer and they have no passion for developer or pride in what they create.

If you don’t enjoy doing something you are not likely to devote much time improving your skills (despite it being their main source income)

They are different from junior developers because often these developers are quite experienced (in terms of years of development experience).

Developers who have not heard/read about OO Principles

Some developers believe if you write code and it does what is required then that’s all that matters.

Many developers believe designing the code to OO principles, creating classes and methods are not needed and don’t.

This will create the code which delivers the functionality but any further interaction with the code is difficult.

Contractors

The quality of CRM Developers contractors is about 60 percent good, 40 percent bad.  I don’t blame the individual contractors because they work to the agreed and existing levels.  If unit tests are not part of the development process then they don’t get written.

I believe all code should be code reviewed but it’s definitely important to review contractors code because you don’t know the quality of their code.  The knowledge a developers code will be reviewed will increase the quality and tidyness before any changes have been found in the code review.

Poor code survives due to the lack of code reviews and lack of Unit tests/code reviews (which often tasks removed when projects deadlines are tight).  Read my blog post Why rushed projects/code doesn’t save time and reduces quality

The benefit of well designed classes offers long terms benefits when interacting with the code.  The long term benefits won’t benefit the contractor who is usually not working on the project after the release.

No Unit Tests

No unit tests leads to the attitude of “if it ain’t broke don’t fix it”.  This is understandable when it’s difficult to test if code changes have broken anything.

When unit tests are written developers can change the code and test their code changes haven’t broken anything.

read more

• Why CRM Developers should unit test their code
• Unit tests are a vital part of emerging code design
• Information to Get started with Unit Testing with Microsoft Fakes and Microsoft Dynamics CRM 2013

Easier

It easier to create poorly written code in one or two big methods than it is to create small classes/functions.  Most CRM developers get the code working and then if there is time, tidy up the code.

Quicker

It’s quicker to create code in one big method, the developer has nothing to think about apart from creating the code.

This method of writing code creates technical debt and fragile code.  The debt of the code will start to eat away developers time whenever they need to understand the code, maintain or extend.

Understanding bad code is is like trying to find things in a messy teenagers bedroom, stuff everywhere and in an order only known to the owner of the room.

Changing bad code is like playing Jenga, changing one bit of code could bring down the whole tower

Consistency

If all the plugins in a project are poorly written there can be some pressure on the developer to create the plugin in the same way and some CRM developers can question the adding of lots of new classes!

It doesn’t make sense to create code which is badly structured, it’s hard to understand and it can’t be tested.  Simple plugins can create code with one or two longs methods with multiple nested if statements and end up confusing.

The fact no code can be reused seems plain crazy, particularly when you consider a lot ofthe code is written using core CRM entities which exist in most CRM projects,

Look at your own plugin code

look at the code you have written recently, how well structured is the code, how reusable is it is

Look in your current CRM projects, how many classes are there

• How many classes?
• How long are your methods?
• Could the code be split up into smaller classes
• What is the average size of the classes and methods
• Are the classes well named? (badly named classes/methods hides code doing many thing not a single thing.
• Are the CRM queries in separate classes or mixed with other code?
• How reusable is the code?

 How Fragile is your code?

A great way to test the fragility of your code is to ask yourself a question

• What happens if the business logic is changed
• What happens if the a new type is added
• What happens if I have to change this plugin

If your code is fragile changing one part of the code could break other parts of the code.  If your plugin code is contained in one or two large methods then the code dependency is high, changing one or two lines could break the whole method.

Fragile code is where a change to one part of the code breaks seemingly unrelated parts of the code.

Is your code designed to minimise the effects of change, e.g. low coupling with independent/modular code.

Look at your plugin code, imagine its going to change and answer these questions

• Is the code easy to change?
• Could I add another type/business logic?
• Can I test the code will work after making the change?
• What is dependent on this code?

It’s an interesting exercise predicting the effects of change on your code and it will provide a warning for areas of code.  You need to factor in the likehood of changes in that area of code.  It’s interesting to do this after the code has been written but very useful to do when you are designing and creating the code the first time.  Which is where the OO design principle came from

Encapsulate What Varies

Here are a couple of interesting articles on the Encapsulate what varies

Find What Is Varying and Encapsulate It

Encapsulate What Varies

Steve Row – Encapsulate What Varies

finally this article on Object Orientated Principles is great

Finally

I shall leave you with these thoughts

Code should be high quality and low in quantity.

No copying and pasting, no duplication.

less code, less places for bugs to hide

CRM Developer Centre gets updated and it looks good

I noticed the CRM Developer website has been spruced up I thought I would write a quick blog about this because I think new CRM developers should definitely head towards the new site.  The change isn’t huge it is a good move for CRM Developers who are just starting out in CRM development.

What is the CRM SDK?

There is the actual CRM SDK, which you download Microsoft Dynamics CRM Software Development Kit (SDK) for CRM Online and on-premises CRM 2015 This gives you a bunch folders and files with sample code and the all important CRM dll’s and maybe a link to the CRM developer toolkit as long as you haven’t downloaded CRM 2015 (Where is the CRM Developer toolkit for CRM 2015?) When I talk about the CRM SDK, I am talking about the documentation.  In the download it’s the CrmSdk2015.chm but I use the online documentation because it’s easier to search. Software Development Kit for Microsoft Dynamics CRM The CRM SDK documentation is awesome but I distinctly remember finding it difficult to use when I was learning CRM development.

Why is the CRM SDK hard to start developing with?

The CRM SDK is a huge and when a CRM developer first starts looking at it can be overwhelmed by the amount of information. When a CRM developer first opens the CRM SDK documentation it’s like walking into the British Library (largest library in the world) looking for a book to get started with programming.

The CRM SDK is a fantastic document and the content is some of the best documentation I have read for product/toolkit but in this strength lies it’s weakness.  The amount of documentation makes it very difficult to order and organise so CRM Developers can find the information they are looking for. Many times I have found useful information

• tucked away in a section I didn’t know existed
• A section I  have never read before
• Wasn’t an obvious place to look.

CRM SDK documentation = CRM Developers bible

I view the CRM SDK documentation as the core documentation for CRM developers, it’s vital CRM developers know how awesome it is, how to use it effectively to clarify how CRM works when they are not sure.

Always start with the CRM SDK

The CRM SDK works brilliantly if you are searching for specific parts of the CRM SDK like OrganizationService, plugin variables. The CRM SDK documentation works well for new releases CRM 2015 SDK – Why you should read the What’s new for developers What’s new in CRM 2015 SP1 for developers, customizers and admins The CRM SDK has lots of example code and offers a good way to learn different CRM customizations.

The biggest benefit of the CRM SDK documentation is it’s written by the creators of the CRM SDK and accurately details how the code works instead of how a CRM developer believes the code works. Most times I read the CRM SDK I learn something new.

The downsides of the CRM SDK documentation is it can read like a manual/reference book, this style is excellent for CRM developers who have some experience but can be confusing for new CRM Developers.  There is a lack of screenshots which can be a barrier to understanding new concepts and examples.

Why the CRM DEVELOPER Centre update is good

Once again the Hosk has gone widely off track, the CRM developer centre has been updated and I think it’s a good thing because

• It’s a front end to the CRM SDK
• It’s modern and sexy looking
• It’s built so it can be consumed on mobile devices
• The search brings back CRM content not all MSDN

The headings give a quick path to relevant sections of the CRM SDK.  It would be great if Microsoft could invest more time trying to visualise the CRM SDK which would encourage more developers to dip in the CRM SDK. The CRM SDK documentation is massive so it’s difficult to dice, slice and display the information in ways to make it easier to find the information you want but Microsoft have already created the information and the challenge is ease accessibility of it.

Experiences of Unit testing with Microsoft Dynamics CRM Projects

Many moons ago when I was a Java developer and learning how to code, I remember two things which had a big impact on my coding.  One was learning about Design patterns and the other was learning about Test Driven Development.

Writing unit tests for your code before you actually write the code seems like a strange thing to do and I didn’t meet many developers who did this or in fact bother writing unit test at all.

I found writing code which you knew was going to be tested with units tests forced me to write modular/reusable code.  It makes you write code which can be tested and usually this means each function does only one thing (because that’s easier to test).

The code is more likely to Single responsibility principle and each class and method doing one thing, the reason for this is because it’s easier to test something which only does one thing.

Pro and Con’s of Unit Testing

When unit tests and writing unit tests are mentioned this question is not usually far behind

What’s the benefit of writing extra code to test your code?

This can be a hard sell to some developers, it would be similar to trying to explain to a messy teenager the benefits of cleaning your room.   One the major complaints raised against writing tests is it takes extra time and we developers don’t have time to do it.

Writing unit tests involves thought and effort creating dummy data, deciding where to mock or stub to get enough data to test the code.  This can feel like a lot of wasted time when you can spend half a day getting the data created to test your code.

This effort can be too much for some developers and they will never like writing units and always view it as a waste of time.  This point of view is a common initial thought until the developer tries it and starts to see the benefits with the improved confidence of their code.

The irony of the aversion to unit testing is developers test their code by creating console apps or debugging the code. Unit testing is taking this process and making it reusable and self-contained

When writing unit test you stop and think about how the code and objects are going to be used.

Below is my experiences of unit testing and CRM, there are probably lots of companies and CRM developers are are unit testing their code

PRO’s of Unit Testing

• confident the code works because it has been tested
• Higher quality code (more modularised/reusable) to enable tests to be written
• Any changes to the code can be tested quickly with no extra effort once tests have been written
• unit tests can help developers new to a project understand how the code (should) work
• very useful for testing refactored or bugfixed code
• It’s easier to debug unit tests than deployed CRM code

CON’s of  Unit Testing

• It takes extra time to write the unit tests and prepare the data
• Unit tests have to be maintained and updated
• You have to learn the testing framework and how to write tests (this is non-revenue generating time)
• A feeling of not moving forward

My Experience of CRM Unit Testing

Unit tests and CRM in my experience have never really happened for a number of reasons/excuses, I have listed them below

Smaller projects

Smaller projects usually remove all non development tasks and reduce everything to the bar bones.  Unit tests were seen as non productive time the customer didn’t want to pay for.

Often small projects had a very limited about of code customizations

Time

Developers never have enough time to do everything the customer wants and usually the first thing to get snipped out is testing and unit tests.  See Why rushed projects/code doesn’t save time and reduces quality

Best Practise/Best Testing framework

Most CRM projects I have worked on haven’t used unit testing.  below I detail some of the reasons this (I’m not saying I agree with them but stating them).  I would say I wasn’t always keen to unit test my code but part of the reason was because the code in the projects wasn’t unit tested.

Cost

Some unit test frameworks do have a cost associated with them.  Microsoft Fakes used to only be included in the Ultimate version of Visual studio (which was very expensive) but it got voted into visual studio premium on Jan 30th 2013.

CRM developers didn’t seem to know (or maybe care) about this because I didn’t meet any CRM developers who liked or did any unit testing of the plugins/custom workflows until recently when I joined my current company.

Joining a project with no unit tests

The decision to unit test usually happens at the start of the project.  Many of the projects I have worked on didn’t have unit tests.

Legacy code impossible to test

Most people don’t bother to try and write unit tests for legacy code.  I can understand this because it would be very difficult

Plugin/Custom workflows hard to test

What do I mean hard to test?  Plugins/custom workflows need a IPluginExecutionContext context so you can test the plugins.  So to properly test a plugin you would need to create a IPluginExecutionContext with the correct attributes.

This would take quite a bit of effort.  To get an idea of all the data created you can use the debugging with the plugin profiler as an example.  When you debug with plugin registration tool, you set it to record the data for a certain plugin, run through triggering it in CRM.  This will create an xml file with all the fields and values.

You can then use this file to recreate the scenario you ran through in CRM and it will pass all those field choices into your Visual studio debugger.   This blog runs through the process

No insistence of unit tests

The projects I worked on, no one insisted unit tests were created, apart from one project.   Instead the code would be tested by each developer and then put forward to an integration test.

Unit testing has to be a company or project policy or something which developers of a company are doing.

Senior developers weren’t doing it

Junior developers learn good and bad habits from senior developers.  In most of the projects I have worked on there were no unit tests.  I haven’t met any (1 or 2) CRM developers who write unit tests and most do not promote unit testing.

Examples to copy

When you type CRM and unit tests you do not get many results back and this suggests unit testing CRM code is not common practise.  More examples and blog posts would make it easier for CRM developers to use this code in their projects.

How Hosk tested his Code

The way I developed my code customizations was to create the code in separate class outside of the plugin code.  I would then create a console app and test the code by passing in a IOrganisationservice, TracingService and Entity.  This allowed me to walk through the code and retrieve data from the development CRM organisation.

I’m not entirely sure how other developers would test their code, I have a sneaky suspicion most would use integration testing (deploy and test it using CRM) and look at the log files.

This article was in draft status for quite a while and in the mean time I have started writing unit tests. I first tried using RhinoMocks and then found Microsoft fakes was free in the premium edition.

I have written the article

Why CRM Developers should unit test their code

I am now a firm believer CRM developers should be writing units for their customizations and there isn’t any excuses why unit tests are not written.  The lack of unit tests is not limited to CRM Development but wide spread in a lot of programming.

There are some difficulties in writing unit tests in CRM but it is achievable using Microsoft fakes.

CRM Project with Tests

There has been a drive to test the code in a project and the developers are writing tests for code which already exists.

I won’t lie this is a tricky a task.  When code hasn’t been written with testing in mind it can be very difficult to test.

I will say some tests are definitely better than no tests and the code was decently structured so a lot of the code plugins are using is now separately tested.

It has taken some time for developers to get to grips with the testing framework and the testing methodology.  Testing is a different mindset and it takes  bit of time to learn the tips and tricks and common testing methods.

The benefits have been

• Tests any developer can run
• The business logic is quite complex in the project, so having a method to step through parts of the code is very useful.
• Tests can be run be developers who didn’t create the code, much quicker than trying to test the code yourself.
• Easier to see if your code has broken other parts of system

Plugins and testing

Some developers can have a blinkered view of testing the plugins themselves.  Plugins are not always easy to test and sometimes a plugin doesn’t do much.

A create plugin might validate values

A plugin could update related records

I personally remove all the code from the plugin and create separate classes where the constructors take IOrganisationService and TracingService.  The method can then take an entity record which has triggered the plugin.

Unit tests can be run against the code which is split up into small focused classes/methods.

At the end you plug all the small tested parts together and link it to the plugin.

Why have I changed my mind about unit tests and CRM

 

Looking at the list of reasons why unit testing was done on the CRM projects I worked, I can see they are not reasons they are excuses.   Most disappointingly is some of the excuses for not writing unit code are excuses I have been making to myself.

I have been reading  Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) and Uncle Bob mentions we as developers/programmers should be testing our code and our code should be good.

He has this quote in Clean Code

Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right. We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.

This year I have been thinking about the quality of CRM code/customizations and have been coming to the conclusion the quality of code in CRM projects need to be better.

I re read my post –  The Frustrations of a CRM Developer many of the frustrations come from poor code.

Quite a few of the CRM Developers articles I have written this year are focused on creating quality customizations

• Bad code is like a virus, don’t get infected
• Why rushed projects/code doesn’t save time and reduces quality
• The problems with complex code and complex CRM Customizations
• Why Code Readability is important
• What’s slowing down your CRM development?

Before reading Clean code I knew I should be writing unit tests but took the easy option of not doing it.  After writing some unit tests for my current development, it has been so much easier refactoring my code and making changes.  Having 40 unit tests testing code change gives me confidence the refactored code works.

Unit testing helps projects from falling into a state of Legacy code because writing code you can tests makes the developer

• Think about the code design
• Think about what the functionality should do
• Test the code more thoroughly
• Creates reusable tests to all developers on the project

I hope this and future blog posts will get more CRM developers to start unit testing their code.

The biggest driver for unit testing code should come from the developer, who has pride in their work and wants to deliver high quality code.  This is an attitude, it’s a desire to create quality code.

The benefits of unit testing are undeniable and if you start unit testing your work you will soon enjoy the benefits.  If you are already writing unit tests then keep up the good work and write a blog about it to encourage other CRM developers.

What is max degree of parallelism option setting in SQL Server?

A ticket opened recently with Microsoft support involved changing a the  max degree of parallelism on the SQL server.

I had not used or heard of this setting before, which isn’t a surprise I tend to leave SQL Server settings to the people who know more about the consequences.

Early in the year I did look at effects of changing the SQL Server trace flag 8780 which resulted in reports running faster but is unsupported unless Microsoft support teams advices you to do it!

CRM SQL Query go faster trick – SQL Server trace flag 8780

My goal in this blog is to give an overview about max degree of parallelism Option and some links to more information.

Remember to always consider the effects of changing flags and options, they can change results/efficiency in other SQL queries

What is max degree of parallelism Option 

The place to start is the MSDN article

max degree of parallelism Option

When SQL Server runs on a computer with more than one microprocessor or CPU, it detects the best degree of parallelism, that is, the number of processors employed to run a single statement, for each parallel plan execution. You can use the max degree of parallelism option to limit the number of processors to use in parallel plan execution. The default value of 0 uses all available processors up to 64 CPUs

You can learn more about Degree of Parallelism in this specific article

This setting is sometimes known as MAXDOP (max degree of parallelism)

Hosk understanding

This max degree of parallelism controls how many processors in the SQL server can be used on any one single query.

The default value for Max degree of parallelism is set to 0, this means there is no limit to the number of processors.

If you change the option to a number e.g. 1, you are then limiting the SQL server to use one processor for each query.

This setting seems to be changed when users want to limit the number of processors used in single queries to stop SQL server taking all the processors for single queries.

The setting is also used to increase the number to improve performance in single queries.

This is a server side setting so you need to consider how changing this setting could effect the performance of all SQL queries on the SQL server (and maybe not just CRM)

More information

This article is very useful because it mentions limitations and restrictions and recommedations

Configure the max degree of parallelism Server Configuration Option

This recommendations I found interesting

• This option is an advanced option and should be changed only by an experienced database administrator or certified SQL Server technician.
• To enable the server to determine the maximum degree of parallelism, set this option to 0, the default value. Setting maximum degree of parallelism to 0 allows SQL Server to use all the available processors up to 64 processors. To suppress parallel plan generation, set max degree of parallelism to 1. Set the value to a number from 1 to 32,767 to specify the maximum number of processor cores that can be used by a single query execution. If a value greater than the number of available processors is specified, the actual number of available processors is used. If the computer has only one processor, the max degree of parallelism value is ignored.
• You can override the max degree of parallelism value in queries by specifying the MAXDOP query hint in the query statement. For more information, see Query Hints (Transact-SQL).

It seems to suggest you can set it on an individual query basis.

Here is another article

Recommendations and guidelines for the “max degree of parallelism” configuration option in SQL Server

How to change the Max degree of parallelism Option

It’s an SQL option so set the value using an sql statement.

I took the code from this page

https://msdn.microsoft.com/en-us/library/dd979074(v=crm.6).aspx

exec sp_configure 'show adv', 1;

RECONFIGURE WITH OVERRIDE;

exec sp_configure 'max degree', 1

RECONFIGURE WITH OVERRIDE;

Exec sp_configure

This is a server wide setting, so it would effect all the CRM organisations you have on the SQL Server and other databases.

How does is this setting used with CRM

Take into account I have not had any personal experience changing this setting, I saw it was mentioned as a possible resolution, I decided to investigate.  

This setting usually effects CRM if you have multiple long running queries.  It can cause the CRM performance to slow.

This article talks about CRM 4

Microsoft Dynamics CRM Server performance is less than expected

In the example above it seems the SQL server was using all the processors on one long running query which caused performance of CRM in general to slow down.  It limits sets the MAXDOP to 1 to stop this.

This article is very good and the blog looks into the setting in detail

Max degree of Parallelism in SQL Server

The article concludes it’s probably best to tinker with this setting only if your having slow performance from your SQL server/CRM.

Other articles

Case Study: Part 1: CXPACKET Wait Stats & ‘max degree of parallelism’ Option: Introduction to Using Wait Stats to Identify & Remediate Query Parallelism Bottlenecks

Case Study: Part 2: CXPACKET Wait Stats & ‘max degree of parallelism’ Option: Suppressing Query Parallelism Eliminated CXPACKET Waits & Liberated 30% of CPU

Interesting forum discussions

Max degree of parallelism setting

A question about the “max degree of parallelism