The Frustrations of a CRM Developer

 

I was reading this article 10 Software Development Frustrations & What You Can Do To Avoid Them!

Being a developer is cool job and most of the time I enjoy it but there are times when it can be the most frustrating job in the world (yes huge exaggeration but I’m being dramatic).  It can make you so angry you want to do this

 

You know the day when you have been at work all day and accomplished nothing, all the things you have tried have failed

It is one of those days when the bugs win

 

Some days you can suffer for the coding art

• Computer setup agony
• Internet down – panic
• spend all day removing code

It coincides with your partner asking

Q.  How was your day today, what did you do?

A.  Nothing, I contributed nothing to the world today

 

I then I was thinking what are the biggest frustrations of CRM developers

1. Opening a Visual Studio project only to find it doesn’t load or compile
2. The code in CRM is different to the source code
3. The cowboy coder who wrote the code has left the company
4. The Development environments are not in SYNC
5. A long manual build process
6. A developers fix breaks lots of other code
7. No coding standards
8.  A disturbing lack of documentation
9. To busy to help
10. No Structure
11. Lack of consistency
12. Customers not working with you
13. Ambiguous requirements
14. Tricky 3rd party software
15. Lack of customer engagement
16. Microsoft release another new version and you have hardly used the last one
17. Having to work on a CRM 4 project
18. Recruitment consultants constantly sending you rubbish jobs
19. CRM Developer toolkit has become unsynced
20. F*%kin solution won’t import
21. NAV, GP and other Microsoft product do not easily sync with Microsoft Dynamics CRM easily
22. yesterday you spent all day writing some code, today the customer doesn’t want it
23. IE crashes for 20th time that day
24. Somebody overwrites you changes in source control
25. Someone does a sneaky IISRESET
26. Debugging on the server
27. A rockstar developer starts at the company and tells you everything you have done is wrong

1.  Opening a Visual Studio project only to find it doesn’t load or compile

You start work on a different project, you eventually find the code in source control, download it.  Open visual studio only to find the flippin code doesn’t compile.  The other developers are all saying “that’s funny, mine compiles”.  Well it’s good that your project compiles but that doesnt help me does it.

Finally someone realises they haven’t checked in some code.

One frustrating morning lost you will never get back

2.  The code in CRM is different to the source code

You are investing a bug, you look at the code and can’t figure out why CRM is working like that.  You inspect the code and find the code deployed is different to the code in source control.

3.  The cowboy coder who wrote the code has left the company

Somehow a cowboy coder was allowed to create project code which is pure spaghetti code without anyone checking any code they had created until they left the company and it was passed to you.  WHAT THE F&%K.  9 times out of 10 that coder was a contractor, it’s funny because it’s true.

4.  The Development environments are not in SYNC

In projects you usually have these environments

• DEV
• TEST
• UAT
• LIVE

Sometimes these different environments can suddenly start to drift apart and where they were once identical.  Suddenly a bunch of customizations are different.

This brings about a lengthy resyncing process, which is a slow painful experience.

5.  Long manual build process

Some projects have a build process which goes on and on and involves lots of manual checking and copying of files.  Followed by a long tedious documentation process which no ever reads until you miss one bug off the list.

6.  A developers fix breaks lots of other code

A developer checks in a fix, triumptly shouts yes, fixed that bug, woo I’m the man.  Suddenly you notice lots of the code you are testing has suddenly stopped working.

The developer god fixes one bug with one hand whilst throwing in a handful of bugs with the other hand

7.  No coding standards

A project had no coding standards, which the developers understood this to mean they could add bad code to the project.  To add to the complex nature of the project each developer has a completely different formatting style.

8.  A disturbing lack of documentation

You start working on a project and find there is no documentation anywhere.  There are no developers who worked on the project.  No one knows anything about the damn project.

9.  To busy to help

To continue coding you need help from one developer/consultant but that person is too busy to help.  You wait at your desk stranded

10.  No Structure

The code is full of big monster methods and the code is tightly

11.  Lack of consistency

Every plugin is written in a different style, all of them confusing

12.  Customers not working with you

The customer consistently ignore your advice and then later say it’s your fault for delivering what they asked for

13.  Ambiguous requirements

There is often a moment in a project when you question a requirement and it turns out no one can understand the requirement or who specified it.

14.  Tricky 3rd party software

You have to integrate the project with third party software specified by the customer.  The API documentation is rubbish, no one has ever written anything about the software on the whole of the internet.  Oh dear this isn’t going to be easy

15.  Lack of customer engagement

A project which is idea of the CEO of the customer company, unfortunately none of the staff want the software and instead prefer to use excel.

16.  Microsoft release another new version and you have hardly used the last one

Flippin heck Microsoft, stop releasing new version of CRM, I’m still working on CRM 2011 projects.

It’s also very confusing having the year in version so we end up using CRM 2015 in the year 2014.

17.  Having to work on a CRM 4 project

Oh no, the CRM 4 project needs an enhancement adding to it.  Now then can any remember how to deploy a plugin, what the hell are these CRM variables.  AHHHAHHHHHH

18.  Recruitment consultants constantly sending you rubbish jobs

I am not a contractor, stop sending me stupid jobs I’m not intereseted in.

NO I’m not interesting in a Junior .NET in Sheffield, GO AWAY

AND BEFORE YOU ASK, NO I WILL NOT RECOMMEND ANYONE TO YOU

19.  CRM Developer toolkit has become unsynced

Nooooooo, my CRM Developer toolkit has become unsynced and now it won’t compile

20.  F*%kin solution won’t import

Listen solution, will you just frickin import, oh for gods sake, ok I will go an assign all the workflows to my user, there are you happy now.

What idiot deleted a variable and has now added it with the same name but different type.

Oh yeah and the error message won’t give you any idea what is actually wrong.

21.  NAV, GP and other Microsoft product do not easily sync with Microsoft Dynamics CRM easily

Listen I understand all the products have Microsoft in the title but the reality is Microsoft brought these different products and they are completely different.

So no customers I am afraid they do not easily sync with each other.

I pity any developer who has to try and use the Dynamic Connector, it is certainly not dynamic.

22.  Yesterday you spent all day writing some code, today the customer doesn’t want it

Yesterday you spent all day urgently adding in some functionality.  Then the customer decides they don’t want it after all and you have to spend all day taking it out. GRRRRRR

23.  IE crashes for 20th time that day

Why, why, why, why, why does IE keep crashing

24.  Somebody overwrites you changes in source control

A developer doesn’t do a get latest and then overwrites your changes, The dirty rotter

25.  Someone does a sneaky IISRESET

Hey what happen, everything has stopped working, I was in the middle of setting up a lot of complex data in CRM.  Oh you did an IISRESET, Thanks buddy.

26.  Debugging on the server

Hey has anyone else’s CRM frozen.   Oh I see we all have to wait for you to debug your plugin on the server

27.  A rockstar developer starts at the company and tells you everything you have done is wrong

A new hotshot developer starts at the company, to get off on the right foot he tells all the other developers they are doing everything wrong.

3 months later everyone realises the rockstar developer is an idiot and after 6 months Elvis has left the building.

 

If I have missed any please add them in the comments

Why you should write code and customizations like a boy scout

As the cost in time and effort of refactoring goes up, developers will add more bad code because it’s easier and quicker.  The result is the bad code in a project is like a snowball being rolled in snow, it just gets bigger and bigger – Hosk

I was reading an article which had the concept of the boy scout rule  boy scout rule, it’s from the pragmatic craftsman and I would recommend the excellent book  The Pragmatic Programmer

If you haven’t read it yet, I recommend you, it will help anyone who has to write any code or is doing any development.

Development and the boy scout rule

Boy scouts have a rule

“Leave the campground cleaner than you found it.”

The other makes this point about code

“the code cleaner than we found it.”

What does this mean

The meaning of the quote with regards to code, is to encourage coders not to add bad code/quick fix code.

I would classify quick fix code as pushing and poking in some code to fix a problem, which adds to the complexity of the code rather than simplifies it.  It might fix the problem but if the code is poorly written and structured it is moving the code towards spaghetti code

If you think about a teenager who keeps putting off cleaning their room by hiding dirty clothes under pillows, shuffling things in cupboards.  If the teenager keeps doing this in the end the room turns into a big mess.  This is ok until the teenager wants to find something, they can’t because stuff is everywhere, there is no order and it’s hard to work out where to look.

Instead of cleaning and tidying up the room, developers when adding bug fixes, keep placing quick fix statements, which over time slowly creates bigger and bigger methods, code complexity increases.  The code because tightly coupled and starts to get more like spaghetti (e.g. code is linked together),  maintaining, enhancing and debugging the code becomes difficult.

This is where the boy scout rule should come into play

“Leave the camp ground cleaner than you found it.”

If you adhere to the rule above it would mean instead of adding quick fix code, you add the code properly which may mean refactoring classes and methods and keeping the code.  It will probably take longer in the short term but it will keep the code well structured, simple and readable (why code readability is important)

Code which isn’t readable (the code which gets the quick fixes) is

• Difficult to understand
• Longer to debug
• hard to maintain
• tricky to extend

The codes growing method/class size, increased coupling and  added complexity results in the code taking more time and resources to maintain in the future.

When changing code you should focus on making it readable and adhering to good programming standards.

The benefits are

• Removes duplicate code
• Easy to understand
• Consistent
• Small methods which do one thing
• Logically structured and designed

What I don’t like about the boy scout rule

The idea is great but when trying to explain this concept to other developers.  For developers/programmers to follow this rule it will result in them doing

• Refactoring code
• Writing better
• Keeping to high standards
• No quick bug fixes
• Increased time and effort to change code
• Increase in Testing

It’s the difference between quickly shoving some clothes in a draw and cleaning the whole room.  Interestingly outside of coding I am very messy person

Acting like a boy scout and follow their rules and tenants is not initially appealing to most developers, particularly if it’s going to take extra time and effort.

My point is it can be hard to persuade other developers to put this amount of effort in, even if they will benefit and save time in the long term.

How do we sell the long term benefit over a short term gain

Help your future self

What I try and do is explain to developers is this will save themselves time and effort in the future and will make their job a lot easier in the future.

If you wrote the code now, there is a good chance you will pulled back into bug fix, maintain and enhance it later on.  When you are working on a project full time, you have a great understanding of the project and you are in the project zone.

Being in the project zone means you understand the code AND all the business rules/business knowledge which goes with the project.  Like sportsman being in the zone doesn’t last and you move onto other projects (although sometimes it doesn’t seem like that).  Due to your extensive knowledge of the project, the business logic and the code you will be the prime candidate to fix any bugs which get raised.

The Messy Garden Shed

If you think of a project customizations like a garden shed.  If every time you use the lawn mower, spades, bird feed, kids toys you tidely place all the items back.  When you need to go into the garden shed a few weeks/months later you can easily find everything without having to remember where you last put things.

If you have a messy garden shed where everything is thrown into the shed and items are over and under each other.  To find the item you want you would have to try and remember what you used last (you might not have been the last user). If you can’t remember you can slowly start pulling things out, looking around.  With everything scattered around it’s difficult to know what’s in the shed, let alone where it might be.

It takes a lot longer to find things in the messy garden shed but if you went into the shed the day after you used the spade, you would have a good chance of knowing where you put it.

The messy garden needs you to remember where things are, this is similar to needing to understand the code and business logic in complex code solutions.

In six months plus time you won’t know the code and you definitely won’t remember the business rules and business logic.

So the code has to be as readable as possible and should not be complex

Scare them

You could try and scare the developers with this great quote

Why you can’t let standards drop

This is a great rule but I’m not sure how effective this would be at movitating people to tidy and refactor the code.  Unless you hired a violent psychopath to walk around the office once a month and maybe do a few code reviews.

Developers should have enough respect in their work to do this as a matter of course or to help themselves out if they have to fix the code later.

Remember

Go round the officing saying this to fellow developers at least once a day

Times may change but standards must remain

Enjoy your work and take pride in creating excellent simple code because as soon as you stop doing it, so will everyone else

 

Should you hire a Rockstar developer for your CRM project?

Articles about Rockstar developers, 10x developers, super developers, etc, etc seem to pop up regularly.  I wondered about Rockstar developers and CRM

• Are there Rockstar developers in CRM?
• What difference would they make?
• What exactly is a Rockstar developer?

My initial thoughts when the term rockstar developer is used

It seems an odd thing to focus on because a single developer can only write a limited amount of code and development and CRM development is a team game.  No matter how good one individual developer/coder is they will have to work with others, communicate with other.

like the average football team who has one super star player, the team can be easily beaten by a decent team all working together, Germany one the world cup using this philosophy.

If you want to read some good posts on the subject of Rockstar developers, I recommend the links below

The Myth of the Rockstar Programmer

Great Hackers – from 2004!

The Myth of the Rockstar Programmer

Rockstar isn’t the right term

Using the word Rockstar doesn’t seem to ring true when talking about Developers because when I think of Rock stars I get the image of cool young people making lots of noise, rebelling against something, worried about looking cool, doing drugs, going to parties, sex, front covers of magazines.

This isn’t the image I get when I think of Developers

Rockstar and programming/developer should be a GoogleWhack – 1, two words which bring back no results because like oil and water they don’t mix (GoogleWhack brings back one result)

What we are really talking about are an experienced and skilled developer

How do you measure a rockstar developer

Q.  How do you measure a rockstar developer

A.  With a tape measure, boom boom.

I’m showing my age, there is probably a tape measure app people would use, but the question is a valid one.  What criteria do you use to measure how effective a developer is.

If you type in how to write good code, you will get pages and pages of results and all of them different

Top 15+ Best Practices for Writing Super Readable Code

Best coding practices

What Makes Good Code Good?

My opinion, code needs to be readable, well-designed, simple and the code should avoid complexity

this quote is pretty good

Junior Engineer – Creates complex solutions to simple problems.
Engineer – Creates simple solutions to simple problems.
Senior Engineer – Creates simple solutions to complex problems.
Rockstar Engineer – Makes complex problems disappear.

Good code makes it easier to debug, extend and maintain, it has to be well structured and decoupled to achieve these

My personal view is a good developer will save you time in the future because there will be fewer bugs, correct architecture chosen, the code will be easier to debug and enhance.

At the time of creating the code an experienced developer and an inexperienced developer might take roughly the same time to create it, most of the problems come later down the line.

Rockstar Developers don’t just write code

When people think about developers the first association will be with code it brings up the question

How long do developers spend writing code?

A more pertinent question for rockstar developers

How long do experienced developers spend writing code?

Senior developers spend a lot less time writing code than most people think.  There are a lot of other tasks

• Gathering/understanding requirements
• Documentation
• Meetings
• Learning
• code reviews/mentoring/explaining
• Code Design

I wrote a blog post 13 signs your CRM project is doomed, if you look at the list of reasons why projects fail the code isn’t usually the problem, project troubles are usually because of the people element of the project.

This is where the concept of a rockstar programmer starts to get confusing, are rockstar programmer/developers great communicators because looking at the list of tasks I would say more than half of their working life will be spent communicating with people.

Code is one of the many small parts of a successful project

What do Senior/Rockstar Developers bring to a company

The most important thing is experience. In my blog post Why .NET developers struggle with CRM Development it highlights the importance of experience.

Avoiding costly development mistakes

Experienced developers have already made lots of mistakes, so the benefit, of hiring an experienced developer, is they avoid making them (mostly) in the future projects.  Not only do they avoid making the mistakes themselves but they also guard against other developers making those mistakes in the projects they are working on.

Create best practice documents

Good senior developers are great for creating best practice documents which are not just built on similar documents and ideas, but based on experience.

Experienced developers are often very good at assessing third-party software

Getting initial integration projects up, running and working can be difficult.  Experience in working with other/simpler third party software and experience of similar projects is vital, senior developers have good processes to work through the problems and create good solid code for other less experienced developers to base their code on.

Helping other developers

Development can be a difficult place for inexperienced/junior developers.  There will be times when they hit a brick wall and are well and truly stuck.  The answer can often be found neatly placed in the experienced developers head.

Experienced developers provide a good example to junior developers via actions and code. Senior developers provide useful guidance for junior developers, keeping their code and customizations adhering to best practices and avoiding nasty code smells.

Calming influence

A good senior developer on a project seems to keep a project calm(er).  The senior developer will help keep the code quality to a good standard.  The senior developer has key input in the design phase of the project using their knowledge and experience.

The design of a project is critical, poor choices can lead to problems later in the project lifecycle.  The later problems occur in a project the more time and resources it will take to fix them.

Create a good team

I don’t think companies should focus on hiring rockstar developers because if you had too many Rockstar they are probably going to clash.  I’m assuming someone who calls himself a rockstar programmer is going to have a big rockstar ego.

The good senior programmers I have met have often been humble people, willing to share knowledge, help others.

When hiring and creating developer department and teams companies need to focus on getting a good team with a mix of skills and experience.

Stop

I’m going to stop using the term rockstar, it just insight right.

Maybe I could use film star, a smooth, suave coding individual like myself, a coding George Clooney if you will.

If anything I would say good senior developers are more like good authors, writing and constructing things

Spine of the team

I don’t recommend companies go searching for rockstars (where do you look to find one?) but I definitely think you need experienced people in key positions.

Like football (again) it often pays to have a strong spine and buy good players in the central positions e.g. Goalie, Central Defense, central midfield and striker.

What happens if you don’t have a senior developer

I worked on a CRM project where there wasn’t an experienced developer on the project, it was a disaster.  Everyone worked as hard as they could but wrong decisions were made, the project wasn’t planned out very well and inexperienced mistakes were made at the worst time possible.

I believe a lot of the mistakes would have been avoided if an experienced CRM developer had been employed for designing the architecture of the project and making sure best practices were adhered to.

The project was rushed and I believe rushed projects produce more code/rushed code.  Rushed code increases the code complexity, read this article The problems with complex code and complex CRM Customizations to understand why it’s bad.

It was a great learning experience for me because I certainly never want to be in that situation again.

Senior developers mentor

Being a developer can be difficult because a lot of the time you will be out of your comfort zone, integrating with SDK’s, 3rd party software, databases, etc for the first time.  This first stage of understanding for developers is getting the code to work.

As you progress you learn more about how the tools/code work and build on your theoretical knowledge.  The building of the knowledge is an important stage because this allows you to understand why things don’t work and logically work out how to overcome this.

Deadlines do not always allow for developers to acquire the knowledge and just need to get things working.  Senior developers can get things working and explain why something wasn’t working and why things work a lot quicker and in a way the developer will understand it.

Senior developers are a safety net

Senior developers act as a safety net and a calming influence.  Even when the senior developer doesn’t have experience in a particular area they the knowledge and experience to calmly work through problems.

Senior developers will help a project and other developers avoid a lot of common errors, guiding the project away from them, like a captain of a ship who has a map, the senior developer can steer the ship through the shallow waters.

What if you have no senior developers

Some companies will believe they can train people on the job and the developers will become experienced.  This is undoubtedly true, but it will involve making lots of mistakes, which could cost the company time and money.

Mistakes in the design of a CRM project can cost many hours in the support/maintenance phase of a project, when extending, maintaining and debugging the project take considerable more time and effort.

Mistakes and problems can be the difference between delivering the project on time and delivering the project late.

Why is this true?  inexperienced developer will

• Take longer to do customizations
• Poor design can lead to problems later in the project
• Make more mistakes whilst learning and gaining experience
• Does not always choose the correct type of customization
• Create complex code and customizations, which are difficult to maintain, debug and extend
• Can have problems integrating with 3rd party software and tools
• Increased likelihood of late delivery of the project (due to problems with code and incorrect estimates)

Not just developers which are important to project

You need good project manager

Project managers can be very important in a project, particular if you have a customer who wants a lot of interaction, questions, change requests.

Good project managers can buffer the development team from constant distractions, keep the project on track, set customer expectations and deal with political situations.

Good senior developers are good at developing, so it can be a waste of their talents if they spend the majority of their time communicating with customers.

A good office culture atmosphere

A good office atmosphere can be the difference between developers leaving and staying.  It’s bad for morale when good developers (or good employees) leave the company.

People spend a lot of their lives at work, so a good working atmosphere is important for the health, well-being and productivity of the employees.

A good office atmosphere can be the difference between your best employees staying and leaving.

Career opportunities

Developers want to feel they are progressing their careers.

Pay your developers enough money

If a developer is on LinkedIn and he has a profile which has been updated in the last 2 years then I can almost guarantee they will be receiving messages from recruitment consultants with suitable jobs.

Even if you take into account the poor quality and scatter gun approach of most recruitment consultants (annoying practices of recruitment consultants) the potential jobs will give the developer an idea what they could be earning.  If the gap between what they are being paid and what they could be paid is too big they cured be lured off to a competitor.

A good mix of experience

Projects and companies need a good blend of experience.  Too many senior developers could lead to frustration at the lack of opportunities.  Junior developers can learn a lot from a senior developer who can help them improve at a good rate because not only will they be able to teach/mentor junior developers but senior developers will be teaching from example (actions, code, processes etc).

So should you hire rockstar developers

If the developer thinks they are a rockstar then probably not, experienced developers spend a lot of time interacting with people (face to face and written communication)

It’s important to have experienced developers in a company they can help set standards, keep projects on track and share their knowledge with many developers.

When hiring a developer you should consider how they will fit into the company culture and other members of the team.  In my experience, great developers do not call themselves rockstar developers so I would think carefully if you found one who does.

Sherlock Hosk and the case of the annoying bug

”How often have I said to you that when you have eliminated the impossible, whatever remains,however improbable, must be the truth?”

Sherlock Holmes Quote

-The Sign of Four

When debugging, eliminate what isn’t causing the problem and whatever code or customization is left must be the culprit.  – Sherlock Hosk

 

I was working on a bug today and I thought I would write a blog about my investigative process.

I had an entity called workshop, in the workshop it had an html grid of another entity maintenance items.

When you selected an item on the grid, it used OData to update the values on the item.

The maintenance item had two values I’m interested in

• Selected
• Manually selected

when I ticked the item, if it wasn’t automatically selected then the manually selected item was set to true and selected sent to true,  The update being an OData call meant the update was instant.

I was viewing the items in another browser I could see the values were updated as expected.

The bug occurred when I saved the workshop something was setting the Manually selected item to false.

What, How, Who

Good developers should ask why five times, I certainly did

WHY, WHY, WHY, WHY, WHY are you doing this to meeeee

So here is how I tracked down the bug

Auditing

Auditing is not a method for bug finding I use very often, I can usually find the problem in the code but I turned auditing on because I wasn’t sure what values were being changed and what was changing the values.

Auditing will show all the changes of fields (assuming you have turned the correct settings), to get an overview of auditing read  a Quick overview of auditing

I was not changing any field values using the GUI but you can never be sure what Javascript/plugins or workflows might be updating fields.

Plugins can update the values either by running as the user or running as a specified user.  In this project the plugins were running as a specified user.  The most common reason a user is chosen is because the chosen user has elevated privileges need to update related records.  Using a specific user means you don’t need to give those privileges to individual or teams of users.

Plugins

I checked what plugins were being triggered.

The plugin would have been triggered on the update event.

I did this by opening the Plugin Registration tool, changed the view to sort by entity and see what plugins are updated on the Workshop update.

When you find the plugins which are triggered you then need to check the plugin filters to see what field changes would trigger a plugin to run

I checked the plugin triggers for the maintenance item as well but this also didn’t have any plugins triggered to change those values.

I searched for the field being changed and it only occurred in a create plugin event, so I knew it definitely wasn’t being triggred.

Workflows

No workflows were being triggered

Javascript

Javascript has three main triggers

• OnLoad – Form Level
• OnSave – Form level
• OnChange – Field level

The OnLoad and OnSave events are triggered when a form is loaded and when a form is saved.  OnChange event is triggered when a field value is changed

I checked the OnSave event and there wasn’t anything which seemed to be updating the values.

I wasn’t changing workshop form values so the OnChange event wasn’t the cause.

Business Rules

This is CRM 2011 system, so there is no such things as business rules here

What now Sherlock?

The sherlock quote from the start comes to mind.

 ”How often have I said to you that when you have eliminated the impossible, whatever remains,however improbable, must be the truth?”

Often when I am stuck on a bug, I find it helps to explain to myself what I know to be true

• The flow of the code
• What I know isn’t causing the bug
• think what else could it be or how can I tackle this differently

The one piece of advice I would give to a junior developer when it comes to bug finding

When finding a bug, change one parameter/field at a time and then test again

The flow of code

• The item maintenance item was changing and updating successfully when clicked
• When I pressed the save button and the form reloading the value was changing
• A plugin was not being triggered
• There were no workflows
• The OnSave Javascript was not updating the values
• No Javascript OnChange event was being triggered

So to quote Sherlock Hosk

When debugging, eliminate what isn’t causing the problem and whatever code or customization is left must be the culprit.  – Sherlock Hosk

The only code left was the Javascript OnLoad

The Game is afoot

Before I go any further, you can buy those beautiful cuff links here for £12, awesome

To test if this was the problem when I saved the workshop I did a Save and Close, which stopped the Javascript Onload from being triggered

Hey presto, the field didn’t update.

I laid a Javascript debugger trap and finally found the code and fixed it.  Gave it a darn good testing and marked the bug as fixed for some futher testing.

Complex code?

 I wrote recently about complex customization in CRM

The problems with complex code and complex CRM Customizations

In this example I would say the complexity has been controlled.

• All the plugins were filtered to only be triggered when certain fields changed
• There were not lots of different customizations overlapping and triggering each other
• The code was structured and logical, I could easily find the code I was interested in

You could argue OnLoad events triggering instant OData queries are slightly confusing/unexpected.

I hope you find this blog post interesting

 

The problems with complex code and complex CRM Customizations

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.  Martin Fowler

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

When writing code you need to keep in mind – Will I be able to  understand this code 6 months later when I have forgotten the business logic – Hosk

This started out as a small blog post, which seems to have kept growing and growing, so be prepared for a long read.  I have a few CRM developer articles which you can find in the section Hosk’s CRM Developer Articles.  It has an article on code readability and why experience is important in CRM development which I recommend you to read.

Before reading the article below I would like you to remember coding is an art, which is one of the reasons it takes a time to learn.  Seeing coding as an art helps to explain why there is no right or wrong way to write code and good code/bad code is open to interpretation.  So the thoughts below are my thoughts on coding and the processes and standards I use, yours might be different but I would love to hear them so please leave a comment.

Complex code

Most developers have been in the situation where you get assigned to a new project and one your first tasks is to resolve a bug. project.

The first step usually when bug fixing is recreating the bug, so I will assume you have done that so now it’s time to look at the code to try to fix the bug.

When debugging some code this is roughly the process I go through

• scan the code
• getting a rough idea of the structure of the code
• work out the flow
• understand the data sources
• Work out what parts of the code are changing the data.

When you come face to face with some nasty complex code, you will see unusually named classes, methods and variables.  There will be some massive methods which seem to do all sorts of things.

“WHAT IS THIS CODE DOING?”

The only way is to debug it line by line

The code is so complex and confusing the most efficient way to understand it is to debug the code, stepping through it line by line, hoping to get some understanding what’s happening and trying to find the elusive cause of the bug.

The code is one big pile of spaghetti code which you are afraid to change, if you are good (and have time) you will do some code refactoring but most likely you will cautiously poke a change towards the code with a long stick, cross fingers it fixes it before slowly backing away hoping to never see the code again.

Why complex code created

 The opposite of simple code is complex code but I would say a lot of code isn’t complex its just poorly written and structured, the main causes of poorly written code (which is often needlessly complex) is inexperienced developers or developers under time pressure.

There is another great quote, which I have paraphrased below from this post – On Credentialism In Software Development

Junior developers create complex code for simple problems

Senior developers create simple code for complex problems

A rushed developer creates code to refactor later

Common reasons for complex code

• Written by a junior developer who is learning
• Quick bug fixes
• Time constraints
• Refactor Later
• No Peer Reviews

Inexperienced/Junior Developer

The reason most complex/bad code is written is because a junior developer hasn’t learned to write simple code yet.  Taking a complex solution and simplying it sounds easy but is extremely difficult in practice.

Time constraints

When developers rush they create code and more code but they do not create better quality code.  Rushed code creates what is called technical debt, which will give you problems later (e.g. when you have to debug or enhance the code).  A note for project managers, pushing developers to extremely tight schedules creates more code

Quick Bug Fixes

When developers add quick bug fixes or bug fixes in general it’s easy to wedge in some code and increase the complexity by veering away from creating simple code.

Refactor Later

Developers know they should write better code/simpler code but they write some code which works and fixes the bug/provides the functionality needed and they promise to “Refactor later”.  You already know how this story ends, the developer is too busy, something urgent pops up and the code is never refactored.

No Peer Reviews

The most effective way to reduce the amount of complex code or bad code is to have a senior developer check the code with a peer review (could also be known as a code review).  The developer won’t let their standards drop and will produce better code when they know it is going to be inspected by another developer.

Peer reviews will also find some bugs in the code and are a great way to guide junior developers into converting complex code into simple code with pointers from the senior developer.

The smells of complex code

Poor code gives off a nasty smell, you maybe able to recognise some of the smells in this wiki article – Code Smell

To understand simple code, I will explain what complex code is and why it makes it difficult.

Here are some of the main culprits of complex code

• Large methods – Monster methods
• confusingly named classes, methods and variables
• methods which do lots of things
• not consistent
• tight coupling
• dependent code
• poorly structured code

Large Monster methods

I’m sure all developers have come across a project where there is one monster method that runs for lines and lines and lines.  They are often full of bug fixes and usually one developers knows the method (the poor soul has had to debug it many times) and often all the bugs flow their way.

People are scared of the monster methods and rightly so because no one can understand it and no one wants to change it.

Plugins are a common breeding ground for monster methods.  I have seen numerous plugins where all the code is directly inside one big method in a plugin.

Developers should not be afraid of changing code

Badly named classes, methods and variables

You know the complexity of code has gone up a notch when you start to see confusingly named methods and variables.  The reason why code gets oddly named is because it’s difficult to name a method which does more than one thing.

Poorly named code makes it difficult to understand the code.

Methods doing more than one thing

Good methods should do one thing well, this makes them easy to understand, easy to debug and fix and easier to reuse.

Complex methods will do lots of different things which makes understanding the method difficult and changing and extending the method scary.

Not consistent

Complex code/poor code will be inconsistent, this can usually occur when a developer has copied the code from various different sources or you have a number of developers working on a project where there is no standards being applied.

The difficulty inconsistently structured code brings is it makes the code hard to understand because there is no common structure, the code has a different flow.

Code and customizations are difficult to understand and not being consistent makes the job even harder.

Tightly coupled/dependant code

Tightly coupled code is code which can’t be reused because it is dependent on other code in the project.  The cause is often because the methods are doing more than one thing and  are really a number of methods (if they were refactored) squashed into one.

Dependant code often can’t be reused even within the same project.

Poorly structured code

Code should be structured and organised in a logical manner.  A simple form of structuring is splitting the business logic and queries into separate methods.

Code structuring makes the code easier to understand and splits into smaller logical areas, this will help in code reuse and bug fixing (because you are isolating the bug)

CRM Customization smells

I have discussed general code smells and complex code, in this section I will focus on CRM complexity.  Below are some of the complex code/customizations I have seen in CRM.

Giant workflows

The CRM GUI for workflows can make it difficult to work with workflows but when you have a giant workflow it can be almost impossible.  There is a limit of four nested if statements in CRM (it’s true for CRM 2011, I’m dangerously assuming it’s still the case in CRM2013/CRM2015 but I could be wrong) and when you have a workflow which is hitting this limit, it’s a sign the workflow is too complex

Read more about four nested if statement limitation

Big workflows are very difficult to maintain and making changes can be very challenging, if you have workflows which are very big you should consider breaking these down into child workflows.

Lots of different customizations overlapping

CRM customizations allow you to provide functionality in lots of different ways.

• Plugins
• Custom Plugins
• Javascript
• Business rules
• Workflows
• WCF webservices
• Console apps

Some customizations are better suited to certain problems and best practices/experience will guide you as to which customization you should use.

I have seen problems where developers have used business rules and Javascript together because business rules don’t trigger Javascript on change events.  By using the different customizations together you are adding to the complexity of the solution and making it difficult for developers to understand the flow.

You can get similar problems when workflows and plugins are used in conjunction with workflows running after the plugin (because plugin is synchronous and workflow is asynchronous) and the workflow overwrites the plugin set value.

I’m not saying using plugins and workflow is wrong and should never be used but care should be taken when they overlap it can create a solution which is difficult to understand and debugging can be puzzling.

When deciding what customizations to use, some consideration of what customizations already exist should be taken into account.  The simpler the solution the easier it will be to maintain and extend the solution later.  When I mention  solutions I am referring to all the customizations as a whole.

Javascript files with duplicated methods

The most common method of structuring Javascript code is having one Javascript file for each entity, CRM pushes people into this model by making you choose a file to upload for the form.  This isn’t incorrect because there will be Javascript methods only suitable for each form because they will be manipulating fields on the form.

This can cause people to copy methods from one entity Javascript file to another entity Javascript file.

What happens later if a bug is found in one of these duplicated methods, usually it gets fixed on one form.  Then you have duplicated code, some of which is fixed and some which isn’t.

No common Javascript files

Following on from the point above, if there are common Javascript functions then put them in a common Javascript file rather than copying the same function many times.

All the code in the plugin

My personal view is you should have no code in a plugin, it should all be moved out to separate classes.

The first reason is you have created a big monster method, which is hard to understand, debug and enhance.

Testing code in a plugin is difficult because you need to mock all the plugin code, if you remove the code from the plugin, you can test the code by just passing in a OrganisationService (e.g. a connection to CRM).

You cannot reuse any code inside a plugin

Copy and paste code (plugins and Javascript)

Complex code means people cannot reuse the code, so they often end up copying parts of tightly coupled code from one area in CRM to another.  This can often lead to messy/poor code but can also allow bugs to slip in with code which isn’t relevant or needed.

The problems with complex code and customizations

 

The code is hard to read

When writing code you need to keep in mind

When writing code you need to keep in mind -Will I be able to  understand this code 6 months later when I have forgotten the business logic.

 

Complex code is hard to understand often because it’s not structured and modularized.  Understanding code which is logically structured into separate classes and small focused methods is easy because the code does what you expect.

Complex code has large methods which do many things, the classes and method names are confusing because it’s difficult to apply a name to a class/method which does many different actions.

Well structured code is like a tidy room, with everything tidied away into draws, bookshelves and wardrobes.  Easy to understand and use.  Things are easy to find.  If you add a new item to the tidy room, you can place it with the other similar items

Complex code is like a messy student room, everything is on the floor.  It’s hard to understand the where everything is or should be.  Objects are to find because you are not sure where to look.  If you add a new object to the messy room, where do you put it and will mess up the organisation of the room.

Slightly improved code is where the messy student buys a big wardrobe and a chest of drawers and chucks groups of things.  You know you need to look in the chest of drawers but if the socks are not in their own drawer it’s going to take you time to find them among the other clothes.

The code is hard to debug

Complex code is hard to debug because it’s because it isn’t structured logically (because it’s in big methods) and the code isn’t easy to understand.  Often the only way to understand what the code is doing is slowly stepping through it.

The code is hard to enhance

When  I mention enhance I am referring to adding new functionality to existing code.  Complex code is usually tightly coupled and changing a big monster method is tricky because you can only test the whole method, rather than a small focused method.

Complex code creates complex bugs

Complex code can create some very tricky bugs which are not obvious to diagnose.

No Reuse

Complex code is tightly coupled and big methods are very difficult to reuse.  It means developers have to write more code, which means more testing.

More code will increase the chance of more bugs.

A lack of reuse in code will result in developers copying parts of code which can result in copy and paste bugs.

Duplicate code will result in bugs where some of the duplicated code is bug fixed and other parts get forgotten about.

Encourages more of the same

Junior developers and developers in general will copy working code.  The good developers will refactor the code, the poor developer will just leave it as it is.

Copying complex code will create more complex code.

If developers see other people creating complex/bad code then they will too.  It’s letting standards drop and everyone will pay for it later down the line when bug fixing takes twice as long

Junior developers will copy it

Developers should set high standards and great code for Junior developers to learn from.

If everyone is creating simple well-structured code, the junior developers will follow their lead.

Summary

Creating complex code/quick code really causes problems for a project later.  Finding and fixing bugs takes a lot longer because the code is harder to understand and fixing the bug is difficult because the code is in large methods and not well structured.

The difficulty in fixing large methods is they do many things and you have to make sure the method still does all those actions and changes.

If you compare this to fixing a small focused method, you only need to make sure it still does the one action.

Complex code creates problems for the project later on where it will become harder to maintain the code whilst fixing bugs and enhancing.  Complex code will mean people take longer to get up to speed on a project, whilst they learn how this individual project is setup and works.

I’m sure lots of developers have worked on legacy projects with complex code and it’s not an enjoyable experience, so make sure you are not creating projects like that.

Tips to boost your career in Microsoft Dynamics CRM

1.  Read Microsoft Dynamics CRM Blogs

Reading blogs is a great way to keep up with the latest functionality in Microsoft Dynamics CRM.  CRM blogs will teach you new functionality, give you common development scenarios and resolve customer functionality you may need to implement.  Blogs are bite sized and focused on particular topics.

A great list of CRM blogs can be found on the Microsoft Dynamics website here

List Top 25 CRM Blogs 

I would recommend adding the blogs you like to an RSS feed reader.

Twitter is also a great way to find interesting CRM blogs, I have a CRM list

 2.  Try new CRM versions

Reading about CRM functionality isn’t enough, you have to get your hands dirty and try it out for yourself then you will have some first hand experience of the functionality.  This exwill be able to judge if you can use it in customer projects.  It’s always a good idea to try new functionality before you have to use it in a customer project, without time pressure.

Microsoft Dynamics CRM make this easy with free 30 days trials, so you have no excuse.

 http://www.microsoft.com/en-gb/dynamics/crm-free-trial-overview.aspx

You can try CRM 2015 now and the new Microsoft Marketing has 30 day trial as well.

Check this link out for more details

3.  What is your dream CRM Dynamics Job

Before you go anywhere, you need to know where you are going or you will never get there.  The same can be said for your career, you need to decide what role in CRM your aiming for

The common Microsoft dynamics CRM roles are

• Senior/Lead Developer
• Consultant
• Solution Architect

Depending on what your current job is you will probably need to climb the ladder of Junior, standard and senior or you may need to be a senior developer before you become a solution architect.

4.  Make a plan

Once you know what you want to do, you can make a plan how to get there.  So work out what role you are aiming for and create a three year plan to get there.

If are you are not sure what skills you need for the role, you can see what skills and experience are mentioned in job adverts for the role.

Once you understand what skill and experience are needed for the role, you can make a plan to build up those skills and build up the experience.

It’s a good idea to let your current employer know you career goal and they will often help you get there because it will benefit the company by bringing an internal employee through because you have experience of the company, the employees and projects.

5.  Get Certified

Lots of people don’t rate certificates but the bottom line is companies (people who employ you) do and customers do.  This isn’t just because I have a bunch of certifications and wrote some material to help you pass MB2-703 CRM 2013 customization and configuration – https://crmbusiness.wordpress.com/mb2-703-crm-2013-customization-and-configuration-certification/

For lots of reasons why you should get certified read this

https://crmbusiness.wordpress.com/2014/03/25/crm-2013-why-you-should-take-and-pass-the-configuration-and-customization-certification/

Quick summary of reasons

• Certified people get paid more and are valuable to companies (who need a number of certified people to get silver/gold partner status)
• certifications are great bargaining chip to take into your next review
• You learn new microsoft dynamics features and parts of CRM you haven’t used before e.g. increased CRM knowledge.

6.  Read books

I love books, they are awesome and think everyone should read more.

Books offer more in depth thoughts on an area or topic and will show you thoughts on a subject by an expert in the field.  I often find thoughts on other topics often shed light give me a different perspective on CRM issues, problems and work practices/processes

Recommended Books for Developers

Coding horror’s fantastic list of books for developers

Even reading books not related to CRM/Coding/projects will give you some benefit and get you away from the screen for a while.

 7.  Go for a walk at lunch

Going for a walk at lunch is not only good for your health but it gives you time to think.  Going for a walk at lunch allows you to step back from your work and see the wood from the trees.

I often come back from my walk at lunch refreshed, energised and usually armed with some fresh ideas on problems I was wrestling with before I went for my walk.

 8.  Write a blog

Writing a blog is a great way to learn new and existing CRM functionality and CRM Development.  Writing a blog will increase your profile in the CRM community and is great to show your current employer or new employees some of your CRM knowledge.

Writing a blog has some external benefits the biggest benefit will be yourself because you will be learning, analysing and sorting your thoughts on different topics.  A great method of learning a subject is by teaching others about that subject, read this blog – why teaching is the best way to learn

I wrote about the reasons I started writing a blog in my new years resolution blog post

The reasons I started writing the CRM blog

• To help me learn about Microsoft Dynamics CRM (CRM 2011 at the time of creation).
• A place for me to easily find solutions to CRM problems I experienced
• To learn more about CRM development by blogging about it
• To help the CRM community
• To raise my profile in the CRM world.

Don’t know what to write

• Write about your last CRM customization, problems and solutions
• What blog posts do you find interesting
• Write about functionality you haven’t used before

 

9.  Keep your social profile up to date

Keep your LinkedIn Profile up to date

Create profiles on

Rockstar profile

 Microsoft Dynamics Community

Create a Twitter account

The reason you should do this is it will help encourage people with similar skill sets to network with you.  If you are answering and interacting in LinkedIn forums and any other forums/websites on the internet, people can view your LinkedIn profile to see what knowledge and experience you have.

A downside or side effect could mean you get InMail from recruitment consultants.   This could be of interest if they offer you attractive roles it will give you some information to take into your yearly appraisal as to what salary (in a rough ball park way) bracket you are in.

10.   Use social media to raise your profile

Write interesting and useful CRM blog, show your CRM skills

Tweet great CRM articles and interesting thoughts about CRM.

Social media is a way to interact with the Microsoft Dynamics community and get to know people who are knowledgable in this area.

if you are not sure about the benefits of Networking read this article

Networking will find you your next job

11.  Watch less TV, Watch Good TV

Watching TV is passive, do something more creative and interactive.   The problem with TV is most people watch too much and you get little back from watching TV.

Watch less TV and use the time to do something more constructive towards your career, otherwise you will have to look back on the year and think, what benefit did watching all the TV have.

You can either watch less TV each night or turn the TV one night a week

 

12.   Research the new CRM add Products

Microsoft has recently released a number of Add in products which are not built into the core Microsoft Dynamics CRM product but offer tight integration.  If you have time look at the products and try it out but definitely spend some time working out what each product does and the benefits/limitations of each product.

Parature

Ringing in the New Year with the Latest Release of Parature, from Microsoft

Microsoft Dynamics Marketing (MDM)

Connecting Dynamics Marketing to Dynamics CRM – Let the Sync Begin

Microsoft Social listening

Unified Service Desk

Microsoft Dynamics CRM 2013 Unified Service Desk

Overview of Unified Service Desk

 

13.  What is social CRM

Social CRM will continue to gain popularity with Microsoft releasing social listening. You will see more and more articles about Social CRM and Microsoft Dynamics CRM.

I believe social media projects will grow in number and size during the forthcoming years and it’s quite possible you may find yourself doing a social CRM project in 2015.

 Read this article 15 social CRM predictions for 2015

The time to start researching and understanding social CRM is now.

14.   Answer CRM Forum questions

Answering questions on the Microsoft Dynamics CRM Forum will

• Learn about common problems people have using CRM
• Learn about new functionality and new releases of CRM
• help the Microsoft Dynamics Community
• Earn badges and raise your profile in the Microsoft Dynamics Community
• focused learning or learning with a purpose

 

15.  Create a CRM slideshow

Put your Microsoft Dynamics knowledge into a slideshow and upload it.  This will enable you to use it again and again.

You can add

You will raise your profile and show case your CRM knowledge

16.  Side project – Create a CRM tool and put it on codeplex

Creating a CRM tool is a great way to get experience developer, create something  useful which can save yourself and many other Microsoft Dynamics CRM users time.

It’s great to put on your CV you have created a tool because you are showing you are a good developer rather than just saying to people you are a good developer.

 

17.   Keep going

It takes a long time to become a CRM expert, don’t expect to be CRM expert overnight.  The key is to not get disheartened, write down your accomplishments this year.

• Experience gained
• new Skills learnt
• Task accomplished
• Achievement

 

Statistics are not a sign of quality but they can be a metric to measure progress in some areas e.g.

• Blog posts created
• Books/pages/chapters read
• Projects worked on
• Twitter followers

 

18.   Start Networking

Get networking, meeting and chatting with people in the Microsoft Dynamics Community.

• Join some groups on LinkedIn answer peoples questions in LinkedIn groups
• Follow people on twitter.
• Comment on peoples blog posts
• Comment on interesting updates on LinkedIn
• Answer Forum questions
• Tweet interesting things, reply to interesting tweets

Build up people you know in the Microsoft Dynamics Community.

Don’t get hung up on the term networking, it all really means it chatting with people who have similar interests.

Networking could also find your next job

 

19.  Stay focused

It’s important to make sure you are working towards your goals and haven’t been blown off course.  This means you constantly need to check you are heading towards the correct goal and focusing your time and effort on activities which add value and are important.  You goal could be promotion or learning new skills.

Check your goal is still the goal you really wan to achieve, analyse your plan to see where you are, what is and isn’t working, update your plan if necessary.

 

20.  What opportunities are there at work

Most people wait for opportunities to be given to them but the problem is you could be waiting a long time.  You have to make

things happen at work

Get the skills needed for the next job e.g

If you want to move to a senior role, what extra technical skills and experience do you need for the role, how can acquire these.  It’s better to

 

21.  Read the Hosk Dynamics CRM blog

I have great articles like this

12 Ways to become a better CRM Developer

and

Other CRM Developer articles

 

 

 

 

CRM 2013 Customization and Configuration Exam notes – Entities and fields

Here are my study notes regarding entities and fields in CRM.  I hope you appreciate the picture of a field (entities and fields, get it?)

Entities and fields are probably an error where most people will have a good starting knowledge of and some experience with.  Don’t get fooled into not studying the topic because there is a difference of using fields and entities and having enough knowledge to answer certification question on entities and fields.

It’s important to understand how entities and fields work and the limitations of them, e.g.

• What entities values cannot be disabled once you have enabled them?
• How does the new functionality like Image work?
• How do entities which are activities work?
• Can you delete fields referenced in a workflow?

 

Whilst studying these two areas I did improve my understanding of the core functionality of CRM and wrote these two blog posts

CRM 2013 – When should you create a custom activity entity?

CRM Entity ownership – How do you decide?

These notes will be added to the other study information I have created, which you can find here – MB2-703 – CRM 2013 Customization and Configuration Certification

Even if you are not studying for the MB2-703 certification, it’s interesting to have a quick read of the notes and I bet you find a fact you didn’t know

Entities

• Microsoft Dynamics CRM default instance starts with more than 260 systems entities but which many are hidden from the UI
• There are two types of entities – Custom entities and system entities
• More than 90 system entities can be customized
• Some system entities cannot be customized e.g. system job
• Entities can be created by the UI, importing records or via code using the SDK
• Entities which can be customized (system and custom) are known as customizable entities
• Not all components of a customizable entity can be customized e.g. system fields like created on cannot be deleted
• Ownership can be either user/team or organisation
• Organization ownerships does not create an owner field, there is no owner or business units
• User/team ownership adds lookup fields for business unit, user lookup, team lookup
• Entities can be owned by users or teams
• You can create custom activity entities
• Activity entities have common fields – planned started date, actual start date, actual end date, description, subject and duration
• All activity entities have a link to the ActivityPointer and can be used in the ActivityParty class
• The activityPointer allows different activities to be viewed in one view.
• Custom Entities when created by default are not viewable/usable to any users apart from System Administrator and System customizer roles. Other security roles will have to add the entity.
• Display name is the name used for the custom entity which the users will see
• Plural name is the name seen in views etc
• Name (schema name) is the customizer name, not seen by end users
• Primary image selected will add a field called image and will allow one image to be added to a each record of the custom entity.
• Primary image, once ticked cannot be unticked
• IF an entity is selected as an activity this cannot be undone
• The primary field is always a single line of text
• Entities in a lookup field will display the primary field value
• Areas that display this entity are areas where the entity will be visible. Changes will be written to the sitemap not part of the entity.
• Additional entity options
• Business process flows – this will create extra fields and cannot be turned off
• Notes, activities, Business process flows, connections, Queues, sending email cannot be disabled if selected
• Allow Quick Create – allows quick create forms which are minimized forms with important fields
• Some default entities have Allow quick create disabled and cannot be enabled.
• CRM For Phones, CRM for tablets, if selected the entities will be available on phones and tablets.
• Renaming entities is not straight forward, labels, reports and views will also need to adjusted
• Custom entities can be deleted if all dependencies have been removed
• System entities cannot be deleted

FIELDS

• CRM 2013 has a maximum of 1023 fields
• For some fields Microsoft adds other fields e.g. currency adds extra fields for Base Currency, exchange rate, currency value and base currency value.
• IN CRM 2011 and earlier the SQL structure was held in two tables. The base table holds the system fields and the extended tables holds the custom fields.  A filtered view was created to show both tables in one view.
• CRM 2013 the two tables are merged but the filtered view is the same.
• The filtered view has been persisted to support reports written using it.
• The filtered view takes into account a user security roles and permissions
• Be careful adding lots of fields to an entity, there are constraints on the SQL database table and views.
• Single line of text can have the format of Email, Text, Text area, Url, Ticker Symbol, Phone
• Single line of text can be between 100 characters to 4000
• IME mode is for Chinese, Korean and Japanese characters
• IME Mode has four modes – Auto, Active, Inactive, Disabled
• Option set – Use Existing option Set if set to yes uses a global option set values
• Two options are always stored as 0 = no – 1 = yes
• Two options will always have a value and cannot be null
• Two options can be formed on the form to be Two radio buttons, Check box or list
• Whole numbers are the SQL server equivalent of an integer (no decimal)
• Whole number format = none, Duration, Time Zone, Language
• Whole number duration is held in minutes
• Floating points can contain a decimal
• Floating numbers are rounded, which means they can be rounded up/down and liable for small rounding errors.
• Floating number precision refers to the number of digits after the decimal, max = 5
• Decimal number is not rounded
• Decimal number precision max = 10
• When a currency field is added to a form, if it’s the first currency field then additional fields of exchange rate, currency, price and base price are also added.
• Currency precision is between 0 and 4.
• Multiple line of text field max length is 1048576 characters
• Date and time field can have the format of Date only or date and time.
• 24 system entities can have the new image field
• Account, Contact, Lead, Product, Competitor, resource, publisher and user have image enabled by default.
• You can add a maximum of one image field to a custom entity
• It is not possible to add an image field to a system entity.
• The entity image will always have the default schema name of entityimage (with no publisher prefix)
• The fixed schema name – entityimage stops more than one image field being added to a custom entity.
• Image field max size is 5 Megabytes
• Image file extensions supported are jpg, jpeg, gif, tif, tiff, bmp, png
• Uploaded images are resized to 144 x 144 pixals
• Field requirement levels are – optional, Business recommended, Business required.
• Requirement levels are form validation only. Importing and plugins do not have to supply data to business required fields
• Fields have a searchable property, if this is set to know the fields will not be displayed in advanced finds
• Auditing for fields can be turned on or off at any time.
• You can bulk edit fields to set Field requirement, Searchable and auditing properties
• Local option set is only available on one form
• Global option sets can be used in multiple forms.
• Custom and system entities have Status and Status Reason fields
• Status is active/inactive
• Status reason (schema name statuscode) has the reason for the status
• Status reason is an optionset of values for each status
• Fields dependencies will not show references in Javascript or web resources.
• You cannot delete a field without removing all the dependencies first.
• System fields cannot be deleted.
• Fields which are referenced in workflows or dialogs cannot be deleted.

Why .NET developers struggle with CRM Development

Experience is important for a CRM Developers. You have to learn how things don’t work first 🙂 no shortcuts

CRM Developers have to learn the mysterious ways of CRM development, they need to learn the the quirks and the way things work with Microsoft Dynamics CRM development.

Microsoft Dynamics CRM can be illogical but we are all used it to now.

If CRM was an animal I think it would be a cat, it’s unpreditable and sometimes very difficult to persuade it to do as you would like

CRM

This makes experience very important because to learn how things work, you have to go through the process of things not working (often in many different flavours of not working) before it works

There are some shortcuts but often you have to go through the painful process yourself.

LIKE WHAT

 

Plugins

When a CRM developer starts developing a plugin, he will learn the all the steps you need to take and the hoops you need to jump through

I went through some of the common problems in this blog but here is a quick recap

• setup up CRM Developer toolkit
• User has to be CRM Admin
• Isolation mode? if none user has to be a deployment administrator
• plugin needs to be signed
• crmRegister file needs to be checked out

These are the simple things you need to do to create and register a plugin, that’s without even thinking about the code and if it works, testing, debugging etc.

CRM tools

There are lots of tools where you have to put the server, the CRM Discovery URL, the OganisationService url.

At first you guess what they are, fail a bunch of times until you knuckle down and find out where those urls are, what they do and why the tool needs them.

Use Microsoft Dynamics CRM services in code

Then one day you find they are hidden in CRM under settings, developer resources!

CRM 2011 – Discovery and organization service are held in settings

WHY .NET/C# struggle developing

Sometimes companies don’t want to pay for CRM developer or have C# resources which they think they will use to do some CRM plugin customization.

This theory seems like a sound idea, the actual C# code in a plugin is usually quite small and not overly complex but for a C# Developer with no CRM experience it’s a total nightmare

C# developers with no Microsoft Dynamics CRM development experience don’t understand how data in the CRM website is structured in SQL Server database

• How CRM works with customizations
• The different types of customizations to choose from, without this knowledge how do you pick the correct customization type.
• How do I create a plugin
• How do you register a plugin – common plugin errors
• How do I write a query to retrieve related records in CRM

Whilst the C# developer goes through learning how things don’t work, it takes the developer a lot longer to write the plugin (if they manage it)

The kicker is if they don’t do constant CRM Development, they will forgot all the lessons they learnt from the work above, slide down the snake and have to learn all again next time.

Hands on experience is vital

The reason hand’s on experience is vital for CRM developers is when a CRM developer is creating customizations and code to work, they will have to overcome a lot of situations where the code isn’t compiling, it isn’t working.  During this minor setbacks you the CRM developers will read blogs, the SDK and work out why it doesn’t work.

The CRM developer will end up with a working customization, e.g. plugin but will also have a better understanding of creating CRM customizations and a more in depth knowledge of how the CRM customization works.

You cannot get this knowledge and experience through reading about CRM customizations like plugins, custom workflows etc.

Creating the customization gives you a deeper knowledge of CRM development because reading about CRM development won’t tell you about what doesn’t work.

If you think about knowledge as 3 dimensional object, reading about CRM Development gives you one view of the object.  Getting it working and overcoming the errors during this process gives you a different view of the object.

Experience is earned

When you start creating CRM plugins, worfklows and other customizations you will run into lots of puzzling problems.  Slowly one by one you will overcome the initial problems and find more intricate problems, which usually move towards logical problems and quirks particular to CRM development.

e.g.

• CRM 2011/2013 – Common Plugin Errors and Isolation Mode
• Microsoft Dynamics CRM not working? check these common causes
• Debugging plugins and getting plugin profiler or remote debugging setup
• You may have problems deploying plugins, like I had which turned out I needed to be a deployment Admin 
• Creating early bound classes, do you use crmsvcutil like this blog post or maybe the early bound generator
• Later you may create a post plugin updating loop and then fix it

The point I am trying to make is CRM Developers learn CRM development by overcoming errors and problems and learning not to make them in the future.

The CRM developer will make less errors whilst creating their CRM customizations (plugins, custom workflows, Javascript, etc), this gives them time to focus on refactoring their code, new functionality, testing, writing better structured code (which is readable).  Their understanding of the underlying CRM structure grows and becomes more in depth.

I view CRM developer progression similar to driving a car.  When you start out driving a car, everything is difficult and you have to think and remind yourself to do these tasks

• Putting on your seatbelt
• Seat right positioned correctly
• Constantly checking all of your mirrors
• Indicating at the correct time
• Changing gears and being in the right gear
• Braking distance
• Estimate distance
• Monitoring speed (and not speeding)
• Understanding what the road signs mean

The driver slowly gets more experienced and begins to do many of the those tasks without thinking, this gives them time to focus on other parts of driving, like not crashing and watching out for idiots on the road.  Driving on the motorway, driving in the rain and snow are all experiences built up over time.  Slowly the driver will become better (hopefully).

The point is you can’t read how to become a better driver, you have to apply the knowledge and experience it yourself.  The same is true about CRM development.

The only way to speed up experience is to do some CRM development outside of work.

Example

Mark McGookin had been working on some CRM development and getting IFrame errors.  Errors messages rarely point to the actual problem as most CRM developer find out.  Error messages are a sign something went wrong and you need to do some detective work to find the root cause.  You can do this by checking your logging, Plugin Trace files, Event Viewer on the CRM server or by debugging the customization.

 

Mark was trying to use Document Management in his code, eventually he found the iFrame error was actually occurring because the SP Root location was null.

Summary

Experienced CRM developers make less errors because they have learnt to stop making these errors through experience and bug fixing those problems.

Due to the experience and knowledge gained through experience and reading they will make better choices about what customizations work well in certain scenarios

One the key roles experience developers have is advising and peer reviewing less experienced developers.  Finding problems and bugs earlier in the process can save you hours if those same bugs are found when the CRM customization has gone to the customer.

 

You can’t import a CRM 2011 solution into CRM 2015

Whilst I was at work on friday 2nd and everyone else seemed to be still on Christmas holiday, I was reading Develop 1 Limited Blog by CRM MVP Scott Durow

Scott Durow has written a framework called SparkleXRM and he has updated it, which you can read about here

http://www.develop1.net/public/post/SparkleXRM-for-CRM2015-with-process-API-support.aspx

The interesting thing I noticed (and I am probably slow on the update here) is he had to make two versions available one for CRM 2011 and one CRM 2015.

This line stuck out

Now that CRM2015 does not support installing CRM2011 solutions I’ve had to branch and make both CRM2011 and CRM2015 versions available

Hmm I didn’t know and hadn’t thought about CRM 2011 solutions and CRM 2015.  I have some study notes for solutions for CRM 2013 CRM 2013 – Understanding Solutions and how they work but what about CRM 2015.

There is an msdn article called Maintain managed solutions for CRM 2015 and the article has this about version compatability.

Version compatibility

Any solution exported from a newer version of Microsoft Dynamics CRM cannot be imported into an older version of Microsoft Dynamics CRM. This includes major and minor versions. You can install solutions exported from Microsoft Dynamics CRM 2011 and earlier releases of Microsoft Dynamics CRM Online into Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM Online 2015 Update. Solutions exported from Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM Online 2015 Update cannot be imported into earlier versions.

Like most MSDN articles is great for cold hard facts, but it’s written to be consumed by robots and computers, which is my way of saying I sometimes find MSDN articles and CRM SDK very factual but bordering on being hard to understand to non robots.  I will preface this by saying writing documentation is a very difficult job the Microsoft do a great job overall.

I read the article, found it useful/interesting/hard to understand, I reread the article and then thought that didn’t sound right because I thought you couldn’t import CRM 2011 solutions into CRM 2015.

 

What’s the truth about CRM 2011 solutions and CRM 2015

I dangerously decided to use the potentially unreliable world of the internet to find out the truth.

I first came to this forum post

https://community.dynamics.com/crm/f/117/t/146740.aspx

This picture definitely seems to say suggest you cannot import CRM 2011 solutions into CRM 2015.  Microsoft uses package version numbers, which is confusing because what are package version numbers

Package Version numbers

I will take a quick side track from the main topic to understand the package version numbers.  There is an MSDN article called Export a solution for a specific CRM version and this talks about new functionality brought in with CRM 2013 Service Pack 1.

CRM 2013 Service Pack 1 was a major enhancement to CRM 2013 (duh that’s why it was a service pack and not a rollup Hosk) and I’m guessing it must have rejigged some fundamental functionality inside CRM 2013.  So solutions created in CRM 2013 service pack 1 and higher would have dependancies on the new functionality in CRM 2013 service pack 1 which wouldn’t be available in CRM 2013 environments earlier than service pack 1 and CRM 2011 environments.

To combat this Microsoft added some functionality to allow you to export solutions which would work in older versions.

The MSDN article has this table which shows us the package version number

IntroducedVersion Value	Solution components introduced
5.0.0.0	Before Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online Fall ‘13
6.0.0.0	Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online Fall ‘13
6.1.0.0	Microsoft Dynamics CRM 2013 Service Pack 1 and CRM Online Spring ‘14

 

I believe CRM 2015 is version 7

Back to Solutions

CRM MVP Jason Latimmer answered the forum post

That was a mistake in the SDK – solutions exported from CRM 2011 won’t be able to be imported into CRM 2015.

CRM 2011 solutions imported into a CRM 2013 environment will function as expected (assuming they use CRM 2015 supported methods) when the organization is upgraded to CRM 2015.

So this suggests you cannot import CRM 2011 solutions in CRM 2015

Next I found this blog post

https://community.dynamics.com/crm/b/magnetismsolutionscrmblog/archive/2014/10/05/upgrading-from-microsoft-dynamics-crm-2013-to-microsoft-dynamics-crm-2015.aspx

Not solutions but upgrades must be CRM 2013 Service Pack 1 or higher

Upgrades to Microsoft Dynamics CRM 2015 must start from Microsoft Dynamics CRM 2013 plus Service Pack 1 or higher.

Finally  I finished with Feridun’s knowledge base

http://fkbase.info/node/224

Solutions

CRM 2013 managed and unmanaged solutions (6.0 and 6.1) can be imported into CRM 2015 (but not CRM 2011)

Verdict

The verdict seems to be you cannot import CRM 2011 solutions in CRM 2015.   This makes logical sense when you consider the changes in CRM 2013 and many of the customizations could be different.

If you had a CRM 2011 solution the best practice would be to upgrade to a CRM 2013/CRM 2015 to check it still worked as expected

So what does this mean

For most people this doesn’t mean anything but if you have a solution you have developed and you want the solution to work in CRM 2015 and earlier versions of CRM then you will need to have two versions.

This probably won’t affect many people because I can’t think of many solutions which would not have changed from CRM 2011 to CRM 2013 (let alone CRM 2015) due to the major GUI rethink in CRM 2013.

It is likely tools and code not touching the front end and using core functionality could be the same.  Core plugin code hasn’t changed much in the from CRM 2011 to CRM 2015 but there is a possibility the CRM 2011 code could be using deprecated methods or the SDK code works differently in CRM 2015.

I would advise people to upgrade the solutions and test the customizations because you can’t be sure they work as expected until you try them.

It does mean if you will need to have two solutions, one CRM 2011 solution and one CRM 2015 solution, in the same way Scott Durow has created two solutions

Why did I blog about this

The likelihood is most people will never have to worry about this scenario, but this is the sort of problem that crops up when people assume they can load up their CRM 2011 solution into CRM 2015.  When you try to do it,  you get errors, a bit of head scratching before you need to import an unmanaged solution into CRM 2013 which you could then export to a managed solution and into CRM 2015.

This is the same version hop you run into if you want to upgrade a CRM version up more than one version e.g. CRM 2011 to CRM 2015, you first have to upgrade to CRM 2013 before you can upgrade to CRM 2015.

 

Upgrade Path

Whislt thinking about solutions, I was thought about upgrading to CRM 2015 and read this blog post CRM 2013 to CRM 2015 Server Upgrade

The blog mentions the upgrade path of CRM must go from CRM 2013 Service Pack 1 to CRM Server 2015.

The only supported upgrade path to Microsoft Dynamics CRM Server 2015 is from Microsoft Dynamics CRM 2013 Service Pack 1 (SP1).

The blog also mentions CRM 2013 server roles are not compatible with a CRM 2015 deployment.  So if I understand the blog correctly it means when you upgrade one server to CRM 2015 the other servers (if you have multiple servers) will become disable and need upgrading too.

I’m not sure when you would have a scenario where you only upgrade some servers but the point about a CRM 2013 server must be at Service pack 1 before upgrading it’s certainly useful to know.

Why Apply rollups before upgrading

When you upgrade CRM two versions e.g. CRM 2011 to CRM 2015, the best practice is to apply the highest rollup or a particular recommended rollup to a certain level before upgrading,

The reason for this is when rollups are applied to CRM they not only include new CRM dll’s/new code and functionality but behind the scenes they can make changes to the CRM database, adding and removing fields.

Adding/removing fields is one reason why you should never create customizations directly agaisnt the CRM database because fields or tables (in reality tables rarely change, but they could!) could be changed/removed during any upgrade or patch release.

Random solution facts

whilst looking for more details on this problem I found this MSDN article, which has a couple of random size issues I wasn’t aware of

Maximum size of solution to import

For Microsoft Dynamics CRM Online the maximum size for a solution is 29.296 MB.

For on-premises organizations, the default maximum size for a solution is 6 MB, but this can be increased as needed.

Really random fact

New Year Hosk CRM Resolutions

I’m sure a lot of readers won’t have any new years resolutions, I admit it is an odd concept to wake up one day and decide you are going to do a bunch of things differently or do new things or stop doing something for the next 365 days.

I think it’s something we should do lots of mini resolutions throughout the year to ensure what you are doing/focusing on is evaluating your current habits/actions to see if they are things you should be doing and focusing on.

When you write a blog you have to conscious you are writing public content available to everyone and people will express opinions on the content you create, this can be viewed as criticism or feedback, the difference is the way you perceive it.  I always welcome feedback, whether it’s good or bad, so please leave comments on the blog.

The Hosk CRM blog and my activities generated some criticism/feedback during the last year

How to Deal with Criticism

My advice is when you receive criticism is not reply immediately and give yourself at least a day to digest the information.  If you find the criticism particularly unfair/annoying/hurtful then think about why, it might be because it’s true.

I am of the view all criticism or comment is useful because it’s feedback on your actions.  Most of the time feedback and getting someone to care about what you are doing is very difficult because most people can’t be bothered to leave a comment/send an email so if they do be grateful (even if you don’t agree with it)

To help you respond and analyise the criticism, draft a reply BUT DONT SEND IT (initially replies are often intent on striking back at the person rather than being constructive), go for a walk and think about the points raised.

Sleep on the criticism

Sleep on your response

The next day(s) look at your response, the criticism will seem less personal and your response is likely to include some comments which are likely to be knee jerk reactions.  You can edit the response and create a more considered and constructive response.  The goal is to take positive points from the criticism and response, otherwise what is the point in replying (there are rarely benefits to negative comments or actions, they usually lead to more negative comments/actions)

here is the first feedback I received

1.  Some people thought I was focused on quantity rather than quality.  Hosk CRM blog focused on the CRM content of other people e.g. blogs/tools/interviews rather than creating CRM content of my own, e.g. a lack of originality

I found this feedback annoying.  Initially I was angry because the CRM MVP interviews I enjoyed creating and coming up with all the questions and getting responses was actually a lot of work.  The blog posts on CRM tools were quite popular.

Rather than replying straight away saying I have written 100’s of original blog posts and indeed if you type a CRM error into google you will often hit one my blog posts with instructions how to resolve it.  Sending this reply wouldn’t have benefited me, so I thought about it.  I replied thanking the person for their feedback and taking the time to write to me, I then forgot about it.

This question nagged at me.  I initially replied stating some facts and figures of the original blog post, YouTube videos etc.  At this point I didn’t understand the point the person was trying to highlight to me.

I had replied like someone participating in an argument, instead of hearing the other person and trying to extract the point and opinion the person is raising, I was just interested in replying with my point of view which disagreed with those comments.

Walking and thinking, thinking and walking

A few months later whilst walking, my mind wandered back to the email (it’s amazing where your mind will go when walking alone) and I started to think more about it.

I realized, my blog was popular getting thousands of views, etc. was it doing what I wanted it to do, was it original

I thought about the reasons I started writing the CRM blog

• To help me learn about Microsoft Dynamics CRM (CRM 2011 at the time of creation).
• A place for me to easily find solutions to CRM problems I experienced
• To learn more about CRM development by blogging about it
• To help the CRM community
• To raise my profile in the CRM world.

I had got blown off my original course, instead of creating original content I was commentating on other peoples original content

Apart from pointing people towards good tools and blog posts what was I getting out of writing blogs about these things, not much.  I would read the articles anyway, but why spend time blogging about the

Instead of blogging about other peoples content I should focus on creating my own.  When I analysed the blogs I enjoyed reading the most, they were often CRM MVP’s who were giving their own opinions, experiences, knowledge, insights and not just a simple how to or a comment on other blogs.  This is what I should be aiming to do, except using my ideas, experiences and thoughts.

 

To me it boiled down to this

Do I want to look back at my CRM blog and think, great job I wrote a popular blog which pointed to great articles written by other people

or

I wrote some great articles with my own thoughts and ideas

 

I started to implement a new attitude to the content created on my blog on 21st September (coincidentally when I moved jobs to NTT Data last year), which possibly doesn’t make it a news years resolution.

This is what I have noticed about creating more

• It’s harder
• My blog posts are longer
• It’s more rewarding and interesting
• I care more about my blog posts because it’s me and my opinion.
• I enjoy thinking about my opinions on CRM functionality, e.g. best practices, deeper understanding of CRM functionality, Advice etc.

I’m not saying I didn’t write any original blog posts before the 2nd September, there are loads but I did spend a lot of time commenting on content which wasn’t mine.

I did write a lot of posts on the MB2-703 – CRM 2013 customization and configuration certification, which you can read here.  It was good to look at the new functionality and get a deeper understanding of some core CRM functionality.  I’m glad lots of people found it useful and helped them pass the MB2-703 exam.

I am extremely grateful to the feedback people give but that particular email has changed my look whole outlook to blogging and this year will see some good blog posts written by myself.   The new outlook on blog post has been influenced by reading some of the books in the post Recommended Reading for Developers and the books on the coding horror list.  Reading great content can motivate you to not only incorporate those techniques into your working day but highlights the possibilities of working smarter.

So this year I want to focus on creating better quality blog post of original content.

Stop tweeting/retweeting the same thing

Earlier in 2014 I was tweeting lots and most CRM articles and someone said stop it, everyone is tweeting the same thing.  I just unsubscribed from A user and now you are retweeting all his posts

This made me think about what I was using twitter for, what was I getting out of it just tweeting every CRM article that moved.

So I stopped tweeting so much and then only tweeted the good articles and some of my old blog posts to remind people about them.

Hosk Aim

To tweet more original thoughts and tweet only very good articles which everyone else hasn’t already tweeted.

Some blog posts copied too much content from other blogs

I totally agree with this.  In my defense I would say I use to do this and my theory was I sharing the information with the readers of my blog, I was promoting useful information to people who might not find it.  I always linked to the original blog/article and recommended readers to visit the original source material.

This isn’t good practice, it possibly takes viewers away from the original and there seems little point to it.  I would advise people to tweet great blog post and write original content, try out some functionality you haven’t used, challenge yourself.

This relates to a previous point about blogging mentioned earlier, I will not be focused on blogging about other people’s CRM content and if there is a good CRM article then I can tweet it or share it on LinkedIn rather than writing a blog about it (unless I have a lot of my own thoughts on the topic of course)

You are focused on racking up points on Dynamics CRM community

This is partly true, because I wanted to collect the meaningless Badge 8 and an MCC badge.   The truth is you can only effectively “rack up” points by answering peoples questions and for them to choose your answer as the verified answer.  Anyone who has tried to do this will know it’s quite difficult to get verified answers because you have to answer before other users, the person has to mark your response as the verified answer.

The bottom line is you have to answer the person’s question to get a verified answer.

Hosk New Years Resolutions

Readers might be curious why I would bother creating this post and detailing my resolutions.  I find creating a blog post helps clarify the points to myself.  A bonus outcome will be it will encourage other people to create original content and set some resolutions for themselves this year.

MORE ORIGINAL HOSK

The Hosk will stand on his blog soap box and shout out advice to anyone that walks by.  I want to focus on creating more original content this year.  My aim is to create better quality content.

More Hosk CRM Dev

My YouTube channel has got over 700 subscribers and some of the most popular blogs are the creating plugins.  So I will create some more plugin and CRM Dev videos.

I was toying with the idea of creating a CRM Dev podcast, but I’m not sure how this would work (hearing but not seeing) or if anyone would be interested.  So I will see about that

Try CRM 2015 new functionality

I currently have only read about the new CRM 2015 functionality and have not yet tried it out myself.

Try TypeScript

I love the idea of TypeScript, I have had a brief look at it here but definitly like to try it out a bit.

CRM Testing

I don’t do enough CRM testing, so this year would like to look at Microsoft Fakes and also the testing frameworks below.

https://visualstudiogallery.msdn.microsoft.com/49e90766-d16d-41b6-8f01-12733a0c27ba

https://xrmtestframework.codeplex.com/documentation

Do an online course in JQuery or JSAngular

JQuery course

http://www.codecademy.com/en/tracks/jquery

https://www.udemy.com/learn-javascript-jquery-from-scratch/

JSAngular

https://www.codeschool.com/courses/shaping-up-with-angular-js

Read some Dev books

 

If you want an easy new year resolution, try the one below

 

pictures Calvin & Hobbs from here