Advice on improving as a Microsoft Dynamics 365 developer

The stupid questions are the ones you didn’t ask #HoskWisdom
I get asked questions directly, I write them as posts so the answer can then help many people instead of just one.  Earlier questions

Ask the Hosk questions

If you ask a question if you are polite it will increase the chance of me answering, don’t forget to say how great my blog is (that really helps).

Consider I’m a busy and sometimes I won’t be able to answer you question.  I might not know the answer.

The CRM Forum

I would recommend raising a question in the CRM Forum

  • It’s free
  • CRM experts who have experience will answer the question
  • Microsoft CRM support answer questions
  • You might get a number of answers and opinions

If no one answers you question then if you email me I can see you have tried

CRM forum

When you raise a question, try to give as much information as possible, this will help anyone who answers your question.

The CRM forums are a great way to learn Microsoft Dynamics 365, you can see common questions raised by users/developers and the answers from experts.

Question – Transition to Microsoft Dynamics is tough

Hi Ben, I have been working on CRM as a consultant/lead for the last 5 years. Earlier I was working on IBM Mainframes/AS400. The transition has been a rough one with trying to learn on the job. Struggling a bit with plugins as .net fundamentals aren’t strong enough. Can you kindly recommend a good learning path?

Its like for every stumbling block I try to Google it out which is kinda taking the fun out of it


I didn’t answer so he reverted to flattery

Hi Ben, I have been eagerly waiting for your response. Would love to hear your wise words

It worked!

Help yourself

When you ask for help, the person wants to know you have tried, got stuck and now you need some advice to set you off in the right direction.  I am reluctant to help people who haven’t tried or thought about the problem because they are taking a shortcut (googling answers, copy code and not learning).

I will go one step further and believe people should think about the problem

Thinking about a problem is the best way to solve it #HoskWisdom


Define what the problem is and work out solutions.  I encourage people to think

It’s useful to use the cardboard developer technique and explain the problem to yourself or a small figure (my preference is a Teenage Mutant Ninja Turtle).

Consultant or developer?

First understand where your destination is before you plot a course.  You should have an ideal job role or identified your next role.  Answer the questions

  • What do I like and dislike about my current role?
  • What did I like/dislike about my previous roles?
  • What is your dream role or dream job?

I recommend going through the Career Conversation as specified by Radical Candor: How to Get What You Want by Saying What You Mean (a great book I recommend it for team leaders/manager)

I think its better to specialise in become either a functional consultant or a developer.  Consider what role you enjoy more because you will be doing it every day for 8 hours.  They are separate roles, which need different skills

Consultant skills

  • Good communication
  • Presentation skills
  • Understanding requirements and analyst skills
  • Running meetings and workshops
  • Strong knowledge of Microsoft Dynamics 365 out of the box functionality
  • Gathering requirements, questioning the business, listening
  • Converting requirements to Dynamics 365 functionality

Developer skills

  • Strong coding skills and experience
  • Design code – SOLID Principles, design patterns
  • Unit testing
  • Integrating systems
  • Software engineering
  • Knowledge of out of the box functionality
  • Debugging, bug hunting

Do everything average or a few things well

I have worked for small companies were my role was consultant, developer, technical setup and support, it was great to learn different aspects of Microsoft Dynamics but I didn’t specalise and I was doing tasks I didn’t enjoy (installing software and configuring servers).

When you work at a bigger companies, you work with experts consultants, developers, DevOps, testers, architects etc.

I think you should focus on becoming either a great Dynamics consultant or a great Dynamics developer but if you try to be both you will be good but not great.  Many Dynamics professionals can’t code and instead focus on improving their consultanty skills.

“The man who chases two rabbits, catches neither.” ~ Confucius

Developer path

I’m a developer, so here is advice on becoming a better developer.

Stop googling answers and think, learning and solving problems, this build up your Microsoft Dynamics 365 knowledge.  Becoming a CRM developer is difficult, it takes time and effort.  Becomean expert in Microsoft Dynamics 365 and improve as a Software Engineer.

No shortcut in become a Dynamics developer

Understand Microsoft Dynamics 365 out of the box functionality, the best way to do this is to take and pass Microsoft Dynamics 365 certifications.

When you come up against problems, don’t search the internet, instead search the Dynamics SDK and understand how it works.  The SDK is the core development engine of Microsoft Dynamics 365

Start with the CRM SDK

The reason to stop getting answers from the internet is because the Internet gives you the answers but it doesn’t help your learn and understand how Microsoft Dynamics 365 works.  Getting answers without learning is short-cutting learning and growing your knowledge.  This leaves  you with fragile knowledge which won’t help you resolve problems not previously tackled.

Known as Chauffeur knowledge

The Two Types of Knowledge: The Max Planck/Chauffeur Test

If you want to improve read books

read the articles below


How to improve as Dynamics 365 developer

Everyone wants to improve but few want to put in the work needed to get better #HoskWisdom

Becoming a champion is not an easy process… It is done by focusing on what it takes to get there and not on getting there – Nick Saban


Improving as a Dynamics 365 developer takes dedication and persistence.  It takes years to build up your experience and knowledge but you can speed up the process by learning from the mistakes and experience of others.

This blog post my advice to Dynamics 365 developers who want to improve.  The core message of the post was written to a frustrated junior developer who wrote me an email simply saying “I want to stop making mistakes and get better, what is the quickest way to improve.”

A few posts improving and tips to improve, start by reading those

No shortcuts

Becoming a good Dynamics developer is difficult and takes time, which is why there are so few good Dynamics developers.

 No shortcuts to becoming an awesome Dynamics 365 developer 

It involves focus, effort and learning from your mistakes.  The more focus on improving the quicker you will improve.   It takes time for your skills, knowledge and experience to accumulate and learn from your mistakes.

Aim to finish work wiser about Microsoft Dynamics than you when you started.  Each day learn something new, improve your skills and reflect on your experiences

If you want to be a better coder then commit to being better and start being a better coder now #HoskCodeWisdom

There is no shortcut, only time and dedication.  Warren Buffett talks about Charlie Munger and his focus

“Charlie, as a very young lawyer, was probably getting $20 an hour. He thought to himself, “Who’s my most valuable client?” And he decided it was himself. So he decided to sell himself an hour each day. He did it early in the morning, working on these construction projects and real estate deals. Everybody should do this, be the client, and then work for other people, too, and sell yourself an hour a day.”

Enjoy being a Dynamics developer

 “You must understand the following: In order to master a field, you must love the subject and feel a profound connection to it. Your interest must transcend the field itself and border on the religious.” ― Robert GreeneMastery 


If you don’t enjoy Dynamics development you will find the work boring and the days long.  If you are not passionate, you won’t care enough and you devote the time needed to improve.

Want to improve

Development is difficult but rewarding when you do it well #HoskCodeWisdom

Improvement comes from within, it‘s a desire to get better.  You need a passion for development, keep motivated, know why you want to improve if you don’t have a good reason you will give up.

It’s a slow process of continuous improvement, end each day learning something new or improving skills.  This is sucking less each day.  Junior Dynamics developers struggle with the limitations of Dynamics 365 functionality, often creating a customisation only to find due to a limitation the solution won’t work.

Why .NET developers struggle with CRM Development

A student mindset uses opportunities to learn and improve,  the more experience and knowledge you build the fewer mistakes you make.

“Most people don’t have the patience to absorb their minds in the fine points and minutiae that are intrinsically part of their work. They are in a hurry to create effects and make a splash; they think in large brush strokes.

Their work inevitably reveals their lack of attention to detail – it doesn’t connect deeply with the public, and it feels flimsy.”
― Robert GreeneMastery

Visualise your day – plan your day

What will you check? What processes will you follow?  When visualizing the perfect day, remind yourself how you should do everything.

Plan your day, make sure you tackle the important tasks and don’t be reactive to change via email or requests.  Developers need to concentrate and focus on one task, avoid switching between many tasks and losing time through switching.

Don’t let email push low priority tasks to the front of the queue,  Email tasks can be the tasks which shout the loudest but the task you do next should be the most important.


Learn from your experiences, review your mistakes you and avoid repeating them.  Inspecting how you work and adapting, keep improving.

Learn from your mistakes, identify patterns, catch yourself from being busy but not productive.

The person who doesn’t learn from their mistakes, repeats them.  Don’t waste your experiences, make the most of them.

Start with the SDK

The CRM SDK is the main tool for a CRM developer, the better a CRM developer knows its capabilities, limitations, and documentation the better they do their job.

Every time you don’t understand something, read the Dynamics 365 SDK, understand it, master it.

Improve code quality

Read Clean Code: A Handbook of Agile Software Craftsmanship.  To write simple code you need to understand design principles are important, they decouple code and avoid making code brittle.

Brittle code with large methods is hard to read and breaks.  When you change one line of code ,it breaks other unrelated parts of the code.  Controlling dependencies and decoupling code allows you to manage the effects of change.

Naming is important, go back over your code and get the names of variables, methods and classes correct.  Like writing a book, developers never give the best names in the first draft, it‘s important to edit, refactor and refine your code.  The first draft gets it working, further drafts are to simplify and improve readability.

Design code

Don’t just write code. Think about it, design it, write it, refactor it, be proud of it #HoskCodeWisdom

Before you start typing, spend time designing your code, find classes and abstractions.  Designed code is easier to read, debug, reuse, unit test, maintain and extend.  All code has an impact, well-designed code minimizes the dependencies

Understand SOLID principles

SOLID principles are the building blocks of good code.  You will produce better quality code, fewer dependencies, and fewer problems later.  SOLID principles help developers recognise good code.

Help yourself

Don’t suffer in silence and sit frozen in front of the code, don’t waste time not making progress.  Don’t look give me the answer, I want to be pointed in the right direction.  Software development has lots of dead ends where to solve a problem you must rule out options and clarify assumptions.

Resolving your own problems is time-consumingbe pragmatic and know when to spend the time learning it yourself and when to get help.

A useful tool is to describe my problems to a toy/cardboard developer,  explaining the problem to the toy and myself I can uncover the solution and I avoid wasting other peoples time.

Why all developers should be friends with a cardboard developer

Understand how Dynamics CRM works

He who knows the most, get’s paid the most #HoskWisdom

Take every opportunity to understand how Dynamics 365 works. A greater knowledge of Dynamics 365 allows consistent choice of the right customisations and enabling quicker trouble shooting.

Dynamics 365 error messages point you in the right direction

Seek out what you are weakest

Improve knowledge and skills, build up your experience.  Don’t hide from these, focus and improve.  Use weaknesses and mistakes as triggers for learning.

Its better to learn functionality before it’s needed on a customer project, where the pressure is on and deadlines are looming.

How to cope when you are out of your Developer comfort zone

Learn from colleagues

Fellow developers are walking, talking troves of knowledge and experience,  learn from their experience.

Colleagues might be useful sources of knowledge but don’t ask them for help without trying to solve problems yourself.  Solving problems yourself gives you the solution and the learning.

The goal is to create customisations delivering the required functionality but it‘s the journey which improves your skills.  Create customisations and get senior developer to ratify your solution.

All developers have tips, tricks and shortcuts which can help you, if you ask and talk to them.

Write unit tests

Know how are you going to test the logic of your code, understand every line of code is doing what it should.

Test your code with unit testsit‘s best practice and encourages you to write decoupled code which is easy to unit test.

A good framework is Unit Testing Microsoft Dynamics CRM using FakeXrmEasy Framework

At Capgemini we structure plugins to separate business logic and repository layer (CRM SDK CRUD) to make testable.

Unit tests are a vital part of emerging code design 

When manually testingDonjust test the happy path

Talk Dynamics 365

Talk Microsoft Dynamics 365 with your colleagues and you will learn something or at worst give information to someone else.

Share knowledge with the team and work together to create a broad knowledge of Dynamics 365 bringing in your differences experiences and thoughts.

Be organised

Don’t waste time looking for files, projects and code.  Be professional, be organised and minimise distractions.

Get Certified

Certifications gives a more rounded and in-depth knowledge of Dynamics 365.  Investigating functionality in Dynamics 365 which they no practical experience of.

Dynamics 365 is the developers main tool, they should know it inside, outside, up and down.

Studying for Dynamics certifications helps to understand the limitations of Dynamics 365 functionality.  Limitations are key factors when deciding the right customization for a requirement.

Average is not good enough

Developer skills are like a snowball, they start off small and quickly pick up speed as your knowledge and skills grow #HoskWisdom

Don’t do average work, do great work.  Customers and other developers can quickly tell if someone is delivering quality work.  Good developers code works well and anticipates the needs of the users, it contains fewer bugs and when bugs are fixed they don’t bounce back.

Developers who work too quickly often don’t fully understand the requirements, don’t clarify them and deliver what they think the users want.  The code contains assumptions and bugs and never seems to be finished

Deliver code you are proud of

Don’t put non-supported customisations

If you write unsupported customisations Microsoft will not support your Dynamics 365 customisations.  A detailed explanation below

Why you shouldn’t put unsupported customizations in Microsoft Dynamics CRM

Know why things are not working

Errors and functionality not working is an opportunity to learn.  Don’t just find the solution on the internet, make sure you take the time to learn what the problem was and how/why it’s fixed.

Microsoft Dynamics CRM not working? check these common causes

The next problem you might get could be different and the better your understanding of Dynamics 365 the quicker you will be able to diagnose the problem.

Read CRM blogs

There are lots of great Dynamics 365 blogs which will help you keep up to date with the latest functionality in Dynamics 365, you can find a great list of them here

I also recommend follow these hashtags on twitter

  • #MSDYN365
  • #Dynamics365
  • #HoskWisdom and #HoskCodeWisdom 🙂

Finally here are some of my other favourite blog posts I have written

Are you a Dynamics Craftsman or a CRM developer?

“Don’t comment bad code—rewrite it.” ― Brian W. Kernighan, The Elements of Programming Style

The quality of your work is related to the standards you set yourself #HoskWisdom


A few months ago I joined Capgemini and people have been asking me what attracted me to join the Capgemini CRM team and what it‘s like to work for Capgemini.  What attracted me is Capgemini’s want to bring software development principles to Dynamics CRM development and focusing on delivering quality enterprise Dynamics CRM/365 projects.

What I really like is Capgemini Dynamics CRM projects have DevOps who setup automated deployments, Continuous integration,  one of the greatest gifts to dynamics developer because it allows more time in creating customisation

Are you a Craftsman?

When interviewing developers I like to ask them if they are Craftsmen or developers, this question finds if the person being interviewed is driving the quality of their work, if they have pride in what they are creating.

Creating quality code like motivation comes from within and can’t be forced using standards or rules.

Dynamics developers need passion – CRM Developers need Passion and joining Capgemini is a good fit because we shared many beliefs.

It‘s importance to keep the quality of CRM projects high and manage technical debt, these principles are even more important on large projects where poor quality code can slow the project and maintaining code can become a nightmare.

I experienced a project where it took 1 day to add an easy fix because a plugin had one method with 2000 lines of code

I can recommend the book

I recommend a few other books in the post – Why isn’t code reused in Microsoft Dynamic CRM projects?

My experience of CRM development

I started out as a Java developer and learnt traditional programmer principles.  Learning about programming and I remember being iinspired by code craftsman and reading Effective Java : Second EditionHead First Design Patterns, Object orientation programming and other books listed on Recommended Books for Developers.

There was a story about a developer learning to become a craftsman, it was featured in a magazine and was a regular column. It talked sbout problems newbie programmers walk into without realising.  (it was called something like the woodcutter or craftsman)

When I moved from Java/.netdevelopment it seemed many CRM development companies didn’t follow good software development practices or good coding standards.

  • CRM code often put all the code into one method in the plugin
  • Lack of classes
  • No unit testing
  • No automated builds
  • No code reviews or static analysis

There are a few reasons for this

  • Microsoft Dynamics CRM made it difficult for automated builds (before solution packager)
  • Companies were not interested in invested in
  • Many CRM projects were small with no budget for automated builds and unit testing
  • CRM developers often didn’t have programming experience or knowledge of SOLID principles
  • Timescales were short in projects – focus on short term gains

Dynamics CRM and developer principles

When I interviewed with Capgemini they wanted to know my opinions on unit testing, code quality.

Capgemini wants to bring software developer principles to CRM but what does this mean?

Capgemini CRM projects are big enterprise integration projects where code quality is important when creating lots of code, which means you will be maintaining lots of code.

Enterprise projects are long projects, technical debt must be kept low and members of the development team adhere to high standards (high standards are a habit)  Here are some of the methods we use to keep quality high

  • CRM DevOps help developers do their jobs
  • Automated deployments/CI environment
  • Solution packager can import data
  • Solution packager splits up customisations to XML file and stored in source control
  • Code check ins to master have to be reviewed and accepted by senior developers
  • Static analysis on code
  • Static analysis errors and warnings must be removed
  • Capgemini hire good Dynamics developers and make them better (join us here)
  • Minimum 90 percent unit test coverage on Business logic code
  • The Quality code message comes from the top
  • The standards implemented on a Capgemini Dynamics project are higher than developers implemented

Regrets I have a few

After working on a project with automated deployments I think this should be a priority for all Dynamics projects to setup on a project, it offers so many benefits which I discuss in the post below

CRM 2016 – Release management, Solution packager and why you should automate your deployment

I wish I had pushed for higher quality on Dynamics projects I had worked on earlier in my career because if you are not writing high quality code you are adding to the technical debt of a project.  I have seen many Dynamics CRM projects start adding technical debt straight from the first line of code because they used poor standards and practices, these projects get harder and harder

It’s great to work on a Dynamics CRM project using software principles.

Capgemini aim to take good CRM developers and make them better by delivering hard projects with well crafted solutions

You can join the Hosk at Capgemini by applying here

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) {

        if (Xrm.Page.getAttribute("field2").getValue() != 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 attribute (client-side reference)

Here is an example using the trusty field2


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) {
        if (Xrm.Page.getAttribute("field2").getValue() != null) {

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.


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


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.


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


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


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

CRM developer centre 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?) CRM SDK download 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.

Hosk CRM DEV Tip – Always filter your queries

Is important to keep good habits and keep your CRM solutions zipping along and in most CRM projects there will lots of queries retrieving records related to the main record.

CRM queries should like Bruce Lee one inch punch.  Mean and Lean with no wasted actions

The one inch punch is so awesome it has it’s own wiki page

The one-inch punch is a punching exercise from Chinese martial arts (kung fu) performed at a range of 0–15 cm (0–6 in). The one-inch punch was popularised by actor and martial artist Bruce Lee. It is designed to improve punching power and technique.

Your CRM code should be as simple as possible 

CRM code and CRM queries should be as simple as possible but not simpler

Last year I was doing some optimization and one of the main culprits of poor performance was due to queries not filtering and returning all rows.  There were examples of no filtering in OData in Javascript and plugins.  You can read more about my investigation into CRM performance here

What to look for

  • new ColumnSet(true))
  • Odata queries with no “filter=”

what are the consequences of not filtering your queries, apart from being on Hosk’s naughty list

Poor performance

The downside of not filtering your queries is you are returning fields you don’t need, this will cause the query to take longer to run and bring down more data for every row returned in your query.

The bottom line is your queries are going to take longer and the more rows you return the worse the performance.

Updating all fields which can trigger more actions

When a query has selected all the fields for an entity another mistake the CRM developer can make is to update the record which updates all the fields in the record.  This can

  • Creating confusing audit trails with fields being updated but not changed
  • trigger workflows and other plugins

I have had some conversations with customers asking why the audit record was saying a field had been updated but no one had changed the field.

The triggering of other plugins/workflows can not only have contribute to poor performance but also trigger new records and values being changed.

Code review shaming

Peer reviews are a great way of stopping poor code like this entering your code.  If the CRM Developer knows the code is going to be code reviewed they are less likely to take shortcuts, write poor code because they know it will be found in a code review.

If a CRM developer does write queries without filters then the code reviewer knows they need to be watched because they are a lazy coder.

Lazy coding

In my blog code Bad code is like a virus, don’t get infected I mention the broken code theory.

If the no poor code had been checked in, the CRM developer would see the code checked in is a high standard, the developer understands the code in this project should be a high standard and will follow the herd checking in high-quality code

If the code repository has been infected with bad code the CRM developer will see it’s OK to check in poor quality code, the easiest action for the CRM developer to take is the quick and easy fix, which is of lower quality and will cost you more time in the long run and make it harder to change the code in the future.

I believe you need to keep the coding standards of a project as high as you can and ensure CRM developers adhere to best practise.  Once bad code gets into source control then you will soon find it starts to grow as other CRM developers check in similar quality code.


There is no excuse to not filter your queries so don’t do it.


Why all developers should be friends with a cardboard developer

I read an article  about a development team who used a cardboard developer.  The team had acquired a life-size cardboard person who they welcomed into the development team.

If anyone in the team had some code which wasn’t working, before asking another developer to sit with them to look at the problem the person had to first get the cardboard developer, stand him next to them, explain the problem to the cardboard developer, run through the code with him to see if he could help see the problem.
I have also learnt this process is known as Rubber duck debugging from the excellent book
The funny thing about this story is quite often the cardboard developer would help resolve the problem.
How exactly does a cardboard cut out help solve development problems and why aren’t companies deploying armies of them.

Stop! walk through the process step by step

The truth is people can often solve their own problems, once they understand the problem and walk through it.
This is what I would term as
can’t see the wood for the trees
This is a saying which regularly gets said, but I’m not sure everyone understands what it really means
Here is an explanation

Meaning: If you can’t see the wood for the trees, you can’t see the whole situation clearly because you’re looking too closely at small details, or because you’re too closely involved.

In terms of CRM development you can get  absorbed in a problem, the methods you have already tried to resolve it, you can get to a point where the CRM developer stops thinking logically about the problem.  For coding problems in particular you can get too close to the problem you forget to use a systematic process of trying to resolve the problem.

A classic example of the cardboard developer – Grumpy IT person

I’m sure many people have called the IT person in their organisation only to find they have given him the role of cardboard cut out.  You calmly explain the problem to the IT person (who is usually grumpy grumpily) to come and try and solve your problem.

When the IT person comes to your desk you go through the steps and it works perfectly and the IT person grunts and goes back to his warm nest away from troublesome users.

Many times I have asked someone to look at a problem and then as I was explaining it to them I instantly knew the answer.  It’s a similar sensation to not hearing someone, saying pardon and then your brain belated tells you what they said.

Why does the Cardboard developer work?

The reason the cardboard developer or any inanimate object works (it helps if it resembles a person or you feel stupid explaining your problem to an apple) is when you explain the problem to someone/something you

  • You have stepped back from the problem, you have stopped to think
  • Go through step by step
  • Explain what you want to happen
  • Explain what is happening
Developers often have to do the same/similar tasks many times they often
  • Engage autopilot
  • Stop thinking and just do
  • Miss steps/Take shortcuts
  • rush

Why should you use the Cardboard developer?

The main reason you should try using the cardboard developer is so you stop wasting other developers time when you could resolve the problem yourself.

Developers need to concentrate for a prolonged uninterrupted section of time (hours) to create a coding solution, this process involves concentrating on a problem with lots of trial and error.  Breaking this concentration for a developer to come and stand by you whilst you resolve the problem yourself can be frustrating for the developer who you have walked round the office and embarrassing for yourself for wasting the developers time.

To avoid wasting developers time I would advise getting up from your desk, going for a walk at lunch, making a cup of tea.  The act of stepping away from your computer will allow you to look at the problem with fresh eyes.

Make sure you use the Cardboard developer to go through a problem first before asking someone else.  I’m not advocating you sit and suffer with a problem but you should make sure you can’t resolve the problem yourself first.

This blog describes why Developers should not be disturbed

Why programmers work at night

or this graphic shows the process which I got from here

Today I used the Cardboard developer

Everyone has to use the cardboard developer and today I should have used the cardboard developer but instead I brought over Sir Les (senior CRM Developer) over to my desk.

I was creating a new development organisation.  I had imported a number of managed and unmanaged solutions.

The next stage was to import some data, I selected the file, press next a few times but then was puzzled why the entities weren’t in the drop down list?

I couldn’t think of any reason why entities don’t appear in drop down lists for importing?

So I got senior developer over.

The act of having someone looking over your shoulder suddenly gets your brain working with more focus.

Have you guessed the problem yet?????

Yes, suddenly it came to me,  I had imported some unmanaged solutions.  Unmanaged solutions need to be published (managed solutions are published automatically).  To understand the intricacies of solutions read my blog post – Understanding how CRM solutions work

Sir Les of CRM Shire was thanked and sent back to his desk, he helped me resolve the problem without doing anything.

Next time I will try explaining it to the cardboard developer before wasting a real developers time.

Check out the Dando the box man adventures

Here and here

Why rushed projects/code doesn’t save time and reduces quality

The idea for this post came when I was driving and listening to the Zen and art of Motorcycle maintenance.

The book is full of interesting questions and will make you look at the world and has some fantastic concepts

It unsurprisingly talks quite a bit about Motorcyle maintenance, which I thought would be boring (I’m not a fan of maintenance with my soft developer hands). One part of the book focuses on how a  mechanic fixes a motorcycle, he doesn’t see the bike as a physical set of tires, metal, etc, he sees it as a whole set of logical systems all linked together. So when the mechanic is fixing a the physical chain, he is fixing the theoretical mechanism which is used to move the wheels.


A recurring theme in the book Zen and the art of Motorcycle maintenance is Quality, it devotes many pages to it.

Here are a couple of good quotes from the book

“The place to improve the world is first in one’s own heart and head and hands, and then work outward from there.”
Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values

Quality tends to fan out like waves.

ROBERT M. PIRSIG, Zen and the Art of Motorcycle Maintenan

You can read about Quality as mentioned in the book by clicking the links below

Pirsig’s metaphysics of Quality

Quality (philosophy)

Whilst listening about quality, I got the idea for this blog post and I pulled over on the hard shoulder and started scribbling in my one of my many super hero notebooks (this one was amazing spiderman)

Alternative titles and quality

The title of this blog post could have been any of these and it will give you an idea of what the blog post is about.

Rushed projects lead to technical debt
Rushed code = Poor Quality code
Quick projects cost you time later
Why quality is important
more speed less quality

The blog post started on the topic of rushed code and rushed projects create the same amount of code but the rushing part reduced the quality of the code and customizations.

It became clear to me whilst writing, it wasn’t due to the speed of the code but the quality of the code was reduced due to the development processes which were omitted.

Rushed Code and Customizations

I’m 99.9% sure all CRM developers and any other developers have had to create some rushed code at some point. Let’s define what I mean when I refer to rushed Code/customizations and projects

Rushed code/customizations/projects involve knowingly missing out steps to deliver the project in a shorter time-scale.

rushed code (usually implemented in rushed project) will miss out steps to deliver code quicker

The assumption made by a lot of project manager/customers is they can remove parts of the development process without reducing the quality of the end product.

The key question is what parts of the development process are removed, to answer this we need to understand the steps in CRM development

  1. Gather requirements
  2. Design architecture
  3. Design code
  4. Write code
  5. Test code via unit tests
  6. Peer review
  7. System Test (GUI)

The goal of the process is deliver the functionality, creating a solution which is as simple as possible with the fewest bugs

Why simple as possible?

I have written about why code complexity is a problem before in the blog post The problems with complex code and complex CRM Customizations

The benefits of Simple code and customizations are
Simple to read and understand
Simple to maintain
Simple to extend
Simple to debug
Simple to test

If you replace the word simple with the word quicker or easier, this explains why simpler code and customizations are so beneficial

The opposite of simple (in my mind) is complex code, below are some of the problems caused by complex code

  • difficult to read and understand the code
  • hard to test
  • difficult to debug
  • tricky to maintain and extend
  • hard and sometimes impossible to test
  • So what steps get removed

The steps most commonly removed from the development process are usually the parts of the process which don’t involve creating customization and code.

  • Code Design
  • Unit Test
  • Testing
  • Refactoring
  • Peer review

As you can see all the non-code parts are removed because the project manager/customers cannot or have chosen to ignore the difference between good code/customizations and bad code/customizations but are merely judging the end product by number of lines of code/number of customizations.

Why are non-code processes removed?

Customers/Manager believe developers are only really working when they are writing code or creating customizations, I’m not quite sure where this idea came from but here are my best guesses

  • When developers first start developing (particularly if self-taught) they start learning by creating code. Inexperienced developers believe developing is writing code and do not yet understand the value of the non-code related parts of development.
  • Code/customization is the end product, so the shortest amount of time creating this must be the most efficient uses of the developer
  • Some developers do not enjoy or see justification for the non-code writing parts of development and don’t do them

It’s a question of quality?

This strikes me as similar to someone building a house but instead of planning and designing the house they just get straight out and start putting down bricks. The end product would be a house but is more likely to be a house which could be huffed and puffed down by a big bad wolf.

When/why is rushed code and customizations

rushed code/customizations are created when things have to be done quick, the kind of estimates which leave enough time to create the code/customizations with no provision for design or things going wrong

Here are the common causes of rushed code/customizations and projects or reasons for missing out development stages

  • Emergency Fix
  • tight/impossible project deadline
  • Change request
  • Quick/Dirty fix
  • Poor development processes
  • inexperienced developers
  • Lazy/poor developers

I originally attributed the removal of development stages to projects/customizations being rushed but it occurred to me the non code development steps are also willing removed by some developers. These developers are usually either inexperienced or poor/lazy developers.

A developer who believes he can write code with little design and no peer review or unit tests will create poor quality code more often than they create good quality code – Hosk
What motivate rushed code/removal of development steps

I will refer to the removal of development steps as rushed code, even though this happens sometimes by choice and not under time constraints, the end result in my eyes is rushed code.

There are two key types of people who create rushed code

Lazy developers

Customers will often push for short time-scales, going against the estimate and advice of developers.

Lazy/poor developers will rush the code because they do not want to either spend time doing a proper code design or often don’t like writing test units or other developers peer reviewing their code.

You can understand the initial logic of customers believing projects delivered in a shorter time scale must be better value.  The customer and the project manager can pat themselves on their backs at getting more for less.

It’s my belief they should be kicking themselves up the backsides because by rushing projects you generating poorer quality projects, which will be a lot more difficult to maintain and debug and likely to contain more bugs.

It is a known practise for some companies to lower bids for projects but the only way they can deliver projects at lower costs is by spending less time creating the code.  Less time spent creating code means the removal of non coding development process.  The consequence of removing the non coding but quality increasing development steps is a reduction of quality in the end product.

Reduced price = reduced quality

A lot of the time the cheaper version of a product is cheaper because the quality is reduced.  If you compare the Apple Ipod to the many cheap MP3 players (which look remarkably like the iPod) there is a difference in quality.  The cheap MP3 players are

  • Feel cheaper
  • break more easily
  • hard to use

In this example you pay less and you get an inferior product, the quality of the product is reduced along with the price.

Rushed code I feel falls into the second category of reduced quality.  The main side effect of reduced quality is increased complexity and a lot of technical debt.

Why do customers ignore quality

When customers push for shorter delivery dates they are agreeing to creating a finished product of reduced quality.

This seems odd behaviour which the same customer wouldn’t do outside of work.  If this customer was getting a house built or hiring a plumber to install a boiler or hire a mechanic to fix their care.  Would the customer

  • Would the customer hire someone who was really cheap but not very good?
  • Would the customer get the job rushed and agree to corners being cut?
  • would the customer allow the house to be built with minimal design and not testing of the house?

The question is why is this behaviour seen as ok with CRM projects, particularly when some CRM projects are big investments for companies.

I believe customers are judging the successful delivery of a project using the wrong criteria.  Projects should not be deemed successful if a version of the CRM project goes live by a certain date.

Successful projects should be judged by

  • What functionality was delivered by the project
  • How many bugs were found in the project
  • Did the project release go without problems

For a CRM project launch to be successful it’s vital the project is released with as few bugs as possible and with key functionality included.  Early setbacks in a project or a disastrous initial release can stop the CRM software from being used by the end users because they can easily lose faith in new software if it’s full of bugs and doesn’t work very well.

A successful release of a CRM project will give the users confidence in the system.

If you get it wrong on the initial release of the CRM project, sometimes you won’t get another chance to win the users over.

Why Quality is important

Apple are a great example of quality products.  Most of the apple products (iPhone, iPod, iPad) are quality products which are easy and fun to use.  This quality allows Apple to sell their products for a high price because the user knows they are buying a quality product and they consumers are willing to pay more.

Quality in code is an interesting concept because CRM Developers can look at some code and in most cases will instantly know if it’s good or bad code but if you ask a CRM developer what are the characteristics of good code, they will stop and think and won’t be able to give you an instant answer.

The design phase of a project and design of code are probably the most important phase of a project and creating code.

The design and structure of code, will sort and organise the code in small simple parts.  This greatly reduces complexity of the code.

The simpler we can make the code the easier it will be to understand the code in six months time when our business knowledge of the code and the system has diminished.  When developer a CRM project, during the development the CRM developer will have very high levels of business knowledge.  The CRM developer will understand the code in detail  will understand the business requirements and rules of the customer.

When the development phase is finished and the CRM developer works on other projects but later works on the original project, the business knowledge and code knowledge of the system will have reduced.  If the code is simple, the CRM developer will easily be able to understand the logic of the code and enhance and debug the code.

If the CRM solution is complex the CRM developer needs the high level of business knowledge to understand the code, this is where rushed projects really suffer.

Rushed projects suffer from technical debt because the development processes which get removed

  • Testing
  • Refactoring
  • design
  • peer reviews
  • documentation

The processes which get removed to save time (or the CRM developer can be bothered to invest the time) are all focused on the quality of the code.   The tasks focus on ensuring bugs don’t exist, the code is as simple as possible and can be tested.   All the processes reduce the number of bugs in the CRM solution and are designed to keep the code well structured and lean.

What does rushed code look like

Rushed code like its distant cousin bad code has a smell.  Code starts to smell when it isn’t right, learn more about code smells by reading the wiki article.

When creating code it’s a constant battle to keep the quality high and the code simple, as soon as the standards start to drop the complexity of the code will start to rise and any interaction with complex code takes longer.

You must control code complexity.  Uncontrolled complexity will drag the code down until no one wants to touch it.

Rushed code and projects is where less time has been spent on designing, planning, structuring the code, testing, reviewing and this will increase the complexity of the code.

Rushed code = greater code complexity

Here are some of the main culprits of complex code taken from here

  • 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 other sign of rushed code is no unit tests and a lack of documentation.

Consequences of rushed code

Quality manufactured goods last a long time and are usually a pleasure to use, the same is true for quality code.   Quality code is great to use for CRM Developers when they are reading/understand, debugging, maintaining and extending.

CRM Projects are expensive investments for companies so it surprises me they want to reduce the quality of the solution created because this I believe should the goal of the CRM development.  Create a high-quality CRM solution which delivers the required functionality and do it right first time.

I believe customers, managers and other people pushing for rushed code should be asked

What is the goal of the CRM project, is it to create a CRM solution quickly or is it to create a quality CRM solution.  Is it time or quality?  The person asking for the rushed code should also be made aware the time saved now should be reinvested later to bring ensure the quality of the CRM solution is kept high.  If the time is not put in later then modifying, maintaining, debugging and extending the code later will all take longer.

The person asking for the rushed code should also be made aware the time saved now should be reinvested later to bring ensure the quality of the CRM solution is kept high.  If the time is not put in later then modifying, maintaining, debugging and extending the code later will all take longer.

Borrowed Time

Producing rushed code is like taking a  short-term loan out, if you don’t pay it back soon then the interest will keep building up.

The currency used with projects and code is time.  Rushing the code will save you a bit of time now but the long-term effects of the rushed code will cost you more time later

Rushed code is like paying for a car using your credit card and then paying back the bill slowly each month. If you want to buy a car you should get a proper long-term loan out.

CRM projects do not seem like the place to want to cut corners and reduce the quality of the end CRM solution by rushing the project to shorten delivery times.  Particularly if the company plans to use the CRM solution for many years to come.

One of the key consequences of creating rushed code and rushed CRM Projects, is any further enhancements or code interaction will take more time and resources.

Rushed code and projects is where less time has been spent on designing, planning, structuring the code, testing, reviewing

The code will contain more bugs

The CRM Solution/Code will not be optimized and could run slower

The CRM solution will have increased complexity

You will have no tests to run against the code base, increased chance of missing bugs.  Unit tests are a valid way for new developers on the project to understand and step through code

Business logic

It’s important to create documentation and tests when you creating the project because you knowledge of the business logic (e.g. customer logic and code logic) will diminish the longer you spend away from the project.

No documentation and unit tests mean you have to relearn everything and this will be more difficult if the code has been rushed because it means the code will be more complex.

More Bugs

Rushed code will likely to include more bugs.  The reason for this is because no unit tests have been written (which can find bugs), no peer reviews of the code.

Bugs found later in a project will cost more time and effort to fix.  You can read the two discussion to find out more

Is it significantly costlier to fix a bug at the end of the project?

Software Defects – Do Late Bugs Really Cost More?

Without having statistical evidence it would seem to me bugs found later would take longer.  If you take into account the process of the customer raising and logging the bug, time to understand and then recreate the bug.  Bug hunting will probably be harder if the person hasn’t used that part of the system or knowledgeable of the code (e.g. not in the project zone).  Moving the code through all the CRM environments.  It seems logical that it’s harder to find bugs later on and then the fixing and promoting the bug fix into live will take longer the later you find the bug in the development process.

Technical Debt

Rushed code will have technical debt due to the short cuts taken to produce the code and customizations faster.

If you don’t know what technical debt is read this wiki article and it’s basically refactoring and changes which you owe the code/project.  Technical debt are code restructuring changes you have put on the list called TO DO Tomorrow.

Just like items you put on the TO DO tomorrow list, they don’t always get done, which means the technical debt keeps growing, which consequently makes tackling it a bigger and bigger problem.

Poor readability

When developers look at code they scan it to get an understanding of how it works.  Before you can debug or extend code you have to understand what it’s doing and how it works, this makes readability very important 

If you struggle to read the code, how the hell are you meant to fix it – Hosk

Rushed code can be inconsistent and complex because it was created quickly.


Rushed code or not creating the code and customizations using all the development steps will create complex code of reduced quality.

Working on rushed projects is not enjoyable, good CRM developers do not like creating rushed code and customizations of reduced quality.  It feels wrong at the time and hard to use later on.

When you create rushed code and customizations any time saved on the creation of the code will be lost when the code is worked on later.

When you create rushed code you are agreeing to create a CRM project of lower quality

12 Ways to become a better CRM Developer

Now and again I get asked how to become a better CRM Developer, so I thought I would create a blog to point people towards and here it is.

1.  Decide you want become a better Developer

Improving and becoming a better CRM Developer is a state of mind/attitude, you have to want to get better, you have to strive to be better every day.

It’s like trying to get someone to read a book you like, you can’t make them read that book no matter how good you say it is, it’s only when the person wants to read it.


2.  Make a plan

A plan is like a map, if you don’t use a map it’s very difficult to get to where you want to go.  A plan is the same for careers and learning skills, you need to identify the skills you want to learn and make a plan to learn them

What areas do you need to improve in?

  • Plugins
  • Javascript
  • CRM 2013 new features
  • CRM 2015 new features
  • WCF webservices
  • Dialogs
  • Certifications
  • programming
  • reports (Bids and SSRS)
  • Data import (Scribe, SSRS)

Make a plan to start learning and getting experience with the above areas.

3.  Read Blogs

I believe all CRM developers should have a selection of blogs on CRM.  These links have some great blogs

Top 25 Dynamics CRM Sites – featured on Dynamics 101

Blogs featured on Microsoft dynamics blog list

Twitter is also a great way to find interesting CRM blogs.

CRM blogs provide technical knowledge and examples of new functionality and CRM development usually written by a CRM expert.

4.  Write blog posts about CRM Development

A great way to learn CRM Development is to write blogs and teach others CRM functionality.  This will not only increase your profile and brand in the Microsoft Dynamics CRM community but you will also understand the functionality better by explaining it.

Clearly explaining how functionality and technical ideas will involve you understanding the topic in greater detail and analyising it before expressing those ideas on your blog.

As an added bonus you will easily be able to find your notes on the subject, I often search my blog solutions to problems and quite often find articles/solutions I forgotten I had written.

Writing about CRM Development reinforces the knowledge, increases understanding of what didn’t work and what did work.

5.  Create Customizations – Write Code

You cannot learn CRM development purely by reading, you have to get your hands dirty and do the development yourself.

One reason practical experience is so useful is getting things to work is a major hurdle in development and until you do you can’t be sure you can or how difficult it is.  The process of getting code to work is usually going through many iterations of the code not working and you learning from your mistakes until you get it working.

Understanding how code doesn’t work gives you a great understanding of how CRM code does work.

The experience of getting an example to work will give you confidence and a working example when it comes to using the functionality in a CRM project.

6.  Learn from your colleagues

All CRM developers have individual areas of expertise their colleagues do not have and you can learn new techniques and skills from your colleagues.   CRM Development and coding is a world where there are millions of classes, methods and functions which it’s impossible to know about all of them, good developers will sniff out the really useful ones but often someone will tell you a technique/method you have never heard of which could make your life loads easier.

You can learn from

  • Peer reviews
  • Reading code written by your colleagues
  • Talking about CRM development

7.  Never stop learning

Becoming a great CRM Developer is a journey which never ends.  There is always

  • New functionality to learn
  • Better techniques
  • New tools
  • New technologies
  • Teaching others
  • Learning from your mistakes
  • Learning from your successes
  • Loads of other things I haven’t mentioned or don’t even know about yet


8.  Stop to think – analyse what you have done

An important step in CRM Development is making sure you stop and think about the CRM development/customizations you have done.

A good time to think about things you have worked on is during a lunch time walk.  Think about how you could have done things differently, the good and bad points.

Analysing your development can help you identify weaknesses in your code and understand why.

For every bad line of code you avoid writing the increased chance of a good line of code taking its place.

Sometimes getting better is not making as many mistakes as the project before.

9.  Don’t take the easy option

If you want to get better you have to constantly push yourself to be a better CRM developer.  This means getting involved in difficult projects and tricky customizations.

Keep up to date with the new functionality in Microsoft Dynamics CRM and try to work on projects which are delivering the latest releases.

Don’t let your standards drop and don’t check in bad code with a promise to refactor it later.

10.  Create free tools – Give yourself a project

Not only will you create something useful for yourself and others, hopefully more useful than this

Hosk’s CRM 2013 Guid Getter

You will learn skills, overcome many problems, get some great experience and learn new skills.

If you are not sure what tool/solution to create then think if there are any things which could be automated in your company or if there something which could be automated or improved in CRM.

It could be Access Team template import/exporter to solve the problem I discussed in the blog post CRM 2013 – Why are access teams marooned?

11.  Read Books

When I say read books, I don’t mean just read CRM or Developer books but you should read all types of books.  Great ideas can come from all areas of life and reading books are a great way to switch off from CRM and focus on something different, you will get ideas/thoughts which will enable you too look at CRM from a different view point.

Some good developer books, which aren’t really about Development I talk about here

Recommended Reading for Developers

The coding horror list is a great list of books, most of them focus on people and processes rather than writing code, which is logical because you will spend as much time interacting with people as you will writing code

Coding Horror – Recommended Reading list for Developers

If you don’t like reading then I would suggest listening to some audio books during your commute or when you are doing the cleaning.

On a personal note, I love science fiction books and have been working my way through the SF Masterworks list

12.  Have other hobbies

Remember, there is more to life than CRM Development so make sure you are spending time with your family and loves ones and get yourself a hobby or a sport, you have to switch off and get your life in balance.


CRM development is great fun, don’t forget to enjoy yourself.