The pressure of IT projects make people doubt themselves at the time they need to believe in themselves

The pressure of IT projects make people doubt themselves at the time they need to believe in themselves #HoskCodeWisdom

It’s easy believing your plan is the right thing to do before the start but when it begins, money is being spent pressure builds and those easy decisions suddenly become scary decisions.

When the pressure is on, people can doubt decisions because now decisions carry consequences but it’s at this moment you need to believe in your yourself and your decisions.

During a project lots of people have opinions,  question decisions and their will be a clamour to decide with guaranteed outcomes.  You can mitigate the problem by making sure you are using the correct criteria for the decision.  The criteria you use to decide is as important as the decision.

Complex decisions contain risk, the result is in the balance and there is a possibility of making the wrong decision.

Don’t fear being wrong

Making the wrong decision or making a mistake is part of the process of getting it right.

You make wrong decisions, live with it, focus on learning, improving and using the feedback to move in the right direction.

This is the time you need to believe, make sure you can justify the criteria, decisions and go for it.  You make the decisions with the information you had at the time, the right decision is only obvious after the outcome.

It’s important for the project to avoid a blame culture and ensure people are not afraid of making mistakes.  You want people to voice their opinions and suggest what they think is right, not scared to speak up.

Wisdom of crowds

Another area decisions are difficult is when a decisions conflicts with the majority, status quo or the way things were previously done.  People are wary of change and are reluctant to support it but there are circumstances when change is needed.  Focus on the facts and highlight the assumptions, this allows you make decisions based on facts not opinions or beliefs.

I will finish with a quote from the zen pugilist Mike Tyson

Everyone has a plan ’till they get punched in the mouth. Mike Tyson

Good code is like underwear. Simple, short and and a joy to look at

Good code is like underwear. Simple, short and and a joy to look at #HoskCodeWisdom

Developers write complex code because they don’t have enough time to write simple code.  To get to a place to write simple code you need to have understood the key requirements and create a simple design.

When explaining a subject, an expert identifies the key points, the hierarchy of knowledge and can explain it.  People who don’t understand a topic jump between points, use 20 words when 5 will do and repeat themselves.

The difference between complex code and simple code is noise; the purpose of the code is unclear with unnecessary steps.  Simple code has clarity, it’s concise and written with a purpose.  When designing code you create excess because you understand the problem whilst you solve it, the design evolves as with your understanding.

Developers skip the design stage and move straight to writing code, it gives the illusion of progress.  The developer learns the solution but the more thought you put into the problem the clearer the solution becomes.  Learning the needs half way through leaves you in a dilemma to adjust what you have or start again.

Writers should not publish an first draft of writing, developers should not release an first draft of code.  You should release when it’s ready, not what you have.

Simple code is created by developers who care about quality, who care about the developers read, maintain and extend it.  Clean code is not written by accident.

Sometimes the most productive day as a programmer is the day you remove hundreds of lines of code and refactor a large confused class into small focused methods

I finish this post with a KISS – Keep it simple stupid

Further reading


Hosk’s recommended Dynamics 365 and other articles August 2018

Sometimes you must stop fighting reality and alight with it - HoskWisdom


I’m an artist, my canvas is Microsoft Dynamics 365 #HoskWisdom

Write fewer lines of code but which do more #HoskCodeWisdom

“To live in the past is to die in the present.” – Bill Belichick

Articles of the Month


Great Dynamics 365 articles this month



Kindle books on offer

The Hosk – currently reading

The Hosk – has read and recommends

Hosk’s CRM Developer Articles

A collection of my favorite CRM Developer articles I have written

The future of Microsoft Dynamics 365 projects

The future of Dynamics 365 projects will be defined by the people implementing them #HoskCodeWisdom

Dynamics professionals should embrace new technologies and services.  Technology changes and evolves and Dynamics 365 projects adapt to take advantage of them.

Microsoft dropped CRM from Dynamics product, projects evolved from case management, sales pipeline and transforming excel spreadsheets into enterprise projects including legacy software, mobile applications, Azure and other services (Social Engagement, gamification, field service).

Future Dynamics 365 projects will combine digital transformation, intelligence and mobile applications to create projects which deliver business value to the customer.  Customers have changed and want cloud and mobile solutions, the focus has moved it of what can we deliver, not what are the technical limitations.

The drivers of solution architecture are complexity, budget and the knowledge of the architect, no the limitations of Dynamics 365.  The environment has changed and small focused apps being consumed on multiple devices.

Junior Developer

  • Delivers Dynamics 365 projects using the skills, approaches and solutions used previously.

Good Developer

  • Uses familiar solutions combined with new servicesfunctionality and capabilities. Understands new functionality but doesn’t have experience.  Uses new functionality on a project making mistakes during implementation.

Great developer

  • Reads, studies and understands new features, services and functionality in Dynamics 365.  Proof of concepts give practical experience to support theoretical knowledge.

Don’t wait

Don’t wait to try new functionalityservices and tools until  needed because that’s too late.  Dynamics practices should investigate and invest in learning to understand when they to use them.

Examples are Flow, PowerApps, Social engagement, field services, cognitive services, Bots, mobile applications etc.  Microsoft hype new tools and release them with basic functionality, making it difficult to use them on projects.  Identifying the limitations and understanding how these tools work lets you know when to use them and when not to.


  • Flow has no way to script deployment
  • PowerApps is evolving with no scripting deployment
  • Field Service often needs customization to add missing functionality
  • Social engagements interaction with social media services

Past projects

Past projects should not be see as reusable template, they should evolve, improving with new functionality and a better understanding how to architect solutions.

Microsoft Dynamics CRM renamed to Microsoft Dynamics 365 was never just about accounts, contacts, sales processes and case management.

Microsoft Dynamics 365 is an XRM framework, a set of tools to create solutions.   Microsoft created dependencies to sales, marketing and case managementThese common requirements were not needed in many XRM projects and created unwanted dependencies.

The latest version of Microsoft Dynamics 365 is now a true XRM framework, you start from a blank slate and use only what you need.

Dynamics projects are not constrained to Microsoft Dynamics 365, they use many Microsoft services (other services are available :-))

• Azure functions and WebJobs allow you to move processing out of Dynamics 365
• PowerApps or quick mobile application
• Common data service enables developers to link data from different sources
• Flow can link different services with Dynamics 365

Breaking free of the shackles of Microsoft Dynamics 365 allows solutions using other services, mobile applications and scaling via Azure. This enables enterprise projects to be created with Microsoft Dynamics 365 at the centre.

Using different services allows Dynamics professionals to tackle different industries, the limit is not technology but imagination and the skill of solution architects.

The future projects of Microsoft Dynamics 365 will include more intelligence and cognitive servicesusing companies’ data proactively to digitally transform businesses.

Microsoft Dynamics 365 continues to evolve, the pace of change is increasing and projects will be bigger, more complex and more fun.

To deliver enterprise projects companies will need to embrace DevOps and bring the best practices of software development to Microsoft Dynamics 365.

How Microsoft Dynamics 365 has changed

Microsoft Dynamics 365 has seen Microsoft move from developing competing products such as Microsoft Dynamics CRM, Nav, AX and now focus on creating services which are used by all Microsoft products.  Microsoft builds supporting services faster which are more feature rich.

New services and tools

  • Flow
  • PowerApps
  • Azure functions
  • Social engagement
  • PowerBI
  • Cognitive services

The challenge in Dynamics projects is working with its limitations, developers initially thought it wasn’t possible to create complex customisations using Microsoft Dynamics 365 online.

With the tools and services available you can create enterprise solutions, much of it without creating code and using Microsoft Dynamics 365 online.  It’s possible to have full DevOps, automating the manual tasks and improving the robustness of the code which are vital to enterprise projects.

The common data service, PowerApps and Azure stop projects from being constrained to Microsoft Dynamics 365 and ease integration with non-Microsoft services/legacy systems. You can integrate multiple services and Microsoft cognitive services to process customers’ data, automate and add intelligence to data and processes.

The future

Microsoft Dynamics 365 will digital transformation of many business and industries, Dynamics professionals will need to know the tools, services and new Dynamics 365 functionality to enable them to create the best solution.

With change comes disruption and opportunity #HoskWisdom

Other articles you might like


Will development move towards no code solutions?

There is nothing to writing code. All you do is sit down and bash you head against the screen for 7.5 hours until you get it right #HoskCodeWisdom

Being a developer is hard, being a good developer is very hard and being a bad developer is merely difficult #HoskCodeWisdom


Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted.  Code is the enemy – Skrentablog

Microsoft are talking about the citizen developer, improving PowerApps and Flow. Should developers and companies invest time and effort to master PowerApps and creating no code/low code solutions.

Customers question the levels of customisation and the cost of creation and maintenance of code.  Everyone line of code costs to create, maintain and extend, code has a yearly cost.

With no code solutions like Flow and PowerApps, Azure manages the lifecycle and performance, leaving the developer focusing on what they should do.

  • Security
  • Scalability
  • Performance
  • Retrys
  • Lifecycle
  • Memory

No code makes the skill level needed to create and maintain lower but how much knowledge do you need to create PowerApps?

Simplifying creating customisations is like moving from C to C# and memory management/Garbage collection. You get better performance doing it yourself but takes more skilled developers but increases complexity in creation and maintenance.

It’s simpler to let a computer manage memory than write the garbage collection routines yourself.  Delegating garbage collection gives the developer more time to focus on creating business functionality code and less time focused on creating plumbing code (which enables business functionality code)

As a Java developer, I hated doing framework code for security, database writing, passing making web pages.  These plumbing code enabled business functionality but took time to write and created extra code to maintain.

When I saw Microsoft Dynamics CRM 4 it was amazing, which is impressive because Dynamics CRM was not amazing!  CRM had lots of out of the box functionality, this meant creating less framework code and I focused on creating customisations to deliver business functionality and Dynamics CRM did the framework and security functionality.

The framework benefits of no code solutions are great, so why isn’t everyone using them?

Managing complexity

I have never worked on a project which didn’t need a plugin or JavaScript/C# code, I imagine this is because the Dynamics projects I work on are larger and need developers.  There are lots of smaller Dynamics 365 projects which can use out of the box functionality.

I work on complex projects with complex requirements, out of the box functionality is limited to the flexibility of the solution it can create.  Can the users change their processes to fit with the out of the box process or do they need custom validation and functionailty.

Requirements and validation are bespoke to each business. A solution should help people do their job, a good solution will automate and validate for users.  Technology should not dictate solutions, it should enable solutions.

When a user selects a field on a form, it should set other values on other fields or validate values, update other fields in the solution. Automate the creation of data, speed up processes and ensure quality data.

These are bespoke to each business but there lies the value. It’s complexity of business requirements which requires JavaScript and plugins.

Design patterns are common patterns to common requirements, can workflows achieve the common problems addressed by design patterns?

Workflows struggle to deliver complexity, they are limited to simple tasks.  Anyone who has created a complex workflow in Dynamics 365 knows they are unmaintainable beasts, as is trying to create smaller focused ones and intertwining them is also difficult. This is due to the workflow editor and trying to visualise complexity with workflows.

Why is hard to deliver complex requirements with workflows, lets understand what does complex code does?

  • Retrieves, complex retrievals possibly using multiple records
  • Sorts, filters
  • Updates
  • Updates and creates related records
  • Validates
  • Deletes

Code should not be complex, it should be focused steps put together. Codes ability to do complex things and combine them makes it powerful.

GUI customisations struggle (Workflows, Business rules) to do complex solutions.
Workflows cannot sort or filter, they can retrieve records which have a direct link to the entity being processed.

Business rules and workflows struggle to validate multiple fields at once and can’t combine fields.

Strengths and weaknesses

The citizen developer is being mentioned, PowerApps and Flows are being seen as the future companies and projects should be heading.  Is this being asked for by customers or pushed by Microsoft?

Flows connect different systems and data sources, they connect and move data between systems/service.  This is mapping and moving data,  standard repeatable process.

PowerApps, Workflows, Business rules are simple customisations but struggle to carry out complex customisations.  When you mix multiple simple customisations, you can end up with a complex customisations which is very difficult to manage.

PowerApps work for one simple app but 500 PowerApps? will citizen developers understand over lapping PowerApps integrate to create one solution.  Will Citizen developers manage PowerApps in different environments (because despite what Microsoft sells, it’s not good practice to make changes directly in production).

These are the things Software Engineers do

  • Unit tests
  • Data Set
  • Integration
  • Design and create simple designs
  • Security
  • Performance
  • Overlapping customisations
  • Naming
  • Create long term customisations which can be maintained and extended

Postives of No Code

There are positives of no code and in certain circumstances it could be the best choice

  • Simple customisations can deliver simple requirements
  • Lower level of knowledge\skill needed to build no code solutions
  • Services manage performance
  • No servers needed
  • Lower maintenance

Code offers solutions which can match the needs of the clients but expensive skilled software engineers need to create, support and maintain it.   The increased flexibility of code costs more.

No code solutions can deliver simple needs and smaller, less complex projects.  The benefits of reduced cost and complexity increase the longer the solution takes to create and maintain.

Comparing the cost of no code/low code and bespoke code should be done over years.  Bugs can hide in both but code means bugs are harder to find and fix.


There will be demand for code because complex requirements need complex solutions.   Code allows you to create solutions to fit companies working practices, the custom validation and automation can deliver big productivity gains.

No code cannot deliver complex requirements but companies can simplify working processes to align to out of box features and no code solutions.The answer can be to have both working together.

The problems happen when you scale and have multiple code/no code components.   You get overlapping, integrating and conflicting customisations and the solution is difficult to understand, manage and extend.

It will be interesting to see where no code solutions lead.  So far the low code solutions don’t seem straight forward and we are still waiting for the functionality to catch up with the Microsoft hype.  When the landscape changes there are opportunities for developers to become experts

further reading


Hosk’s Recommended Dynamics 365 Articles July 2018


You cannot forget when you do something amazing #HoskWisdom

Projects and code always take longer than expected #HoskWisdom

The pain of legacy code never goes away

Articles of the Month


Best of the rest



The Hosk – currently reading

The Hosk – has read and recommends

Hosk’s CRM Developer Articles

A collection of my favorite CRM Developer articles I have written

When a Patch to Microsoft Dynamics 365 can break your instance


“When you come to the end of your rope, tie a knot and hang on.” — Franklin D. Roosevelt

We had problems importing solutions in a sandbox instances for Microsoft Dynamics 365. It was because different instances having different versions of Microsoft Dynamics 365. This article looks at the potential problems of patches.


We have been upgrading customisations to make them Microsoft Dynamics 365 version 10 compliant and removing the customisations which are depreciated in Microsoft Dynamics 365 version 9.

You can find a list of the important changes and what’s depreciated here:

There can be confusion about what you need to update with new versions. Microsoft supports the last 2 releases: Microsoft Dynamics 365 version 8 and Microsoft Dynamics 365 version 9. Customisations are depreciated in Microsoft Dynamics 365 version 9; they will still work in the current version, but it means you can’t use them in Microsoft Dynamics 365 version 10.

An example if the client api is depreciated


Now need to get the FormContext


so before you would have done this

var firstName = Xrm.Page.getAttribute(“hosk”).getValue();

now you need to do this

var formContext = executionContext.getFormContext();

var firstName = formContext.getAttribute(“hosk”).getValue();

You can make the change now but you only HAVE to make this change when you are using Microsoft Dynamics 365 version 10.


The Capgemini Dynamics team store customisations in source control, this allows us to create solutions and deploy them into new environments (we can create an environment and deploy all customisations with a click of a button). We can see the changes in Microsoft Dynamics 365 customisations.

We compare the xml changes of forms, views, JavaScript and all customisations. This week we noticed in the last patch Microsoft added a new section and JavaScript to the contact entity.

This raised the following questions:

1. Should this change happen in a patch release?

2. With Microsoft’s new direction of making all customisations as solutions, wouldn’t this functionality be optional?

3. What functionality could Icebreakers be? Would Microsoft suggest Icebreakers or you store them for each contact?

4. Patches are not meant to break functionality


A new section added to the form which could confuse testers and users, but it breaks the deployment because it added a dependency to new internal solution added.

We got an error about missing dependency to “Icebreaker  solution and msdyn_talkingpointsloader.js web resource during deployment testing on a separate tenant. The sandbox instances were upgraded with the latest patch, while extracting the latest changes, the section changes with some web resources and controls, adding dependency to “Icebreaker” solution.

Dev instance is version

Test instance is version

Between– (DB version) this solution and dependency was added, making it difficult to use multiple tenants because Microsoft controls when patches are installed. You can get into a situation where some of your instances have had a patch applied whilst you are waiting for Microsoft to apply patches for others.

When we put code into source control and include Microsoft’s changes, we then cannot install these solutions into the instances which have not had the patch applied.

Here is the Unhandled Exception:

System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: The action was failed after 0 times of retry. InnerException is: Microsoft.Crm.Tools.ImportExportPublish.ImportSolutionException: Solution manifest import: FAILURE — -> Microsoft.Crm.Tools.ImportExportPublish.ImportSolutionException: Solution manifest import: FAILURE — -> Microsoft.Crm.CrmException: The following solution cannot be imported: feature_Customisations. Some dependencies are missing. The missing dependencies are : ><Required key=”1510″ type=”66″ schemaName=”MscrmControls.TalkingPointsControl.TalkingPoints” displayName=”MscrmControls.TalkingPointsControl.TalkingPoints” solution=”Icebreakers (” /><Dependent key=”125″ type=”60″ displayName=”Contact” parentDisplayName=”Person” id=”{1fed44d1-ae68–4a41-bd2b-f13acac4acfa}” /></MissingDependency><MissingDependency><Required key=”1536″ type=”61″ schemaName=”msdyn_talkingpointsloader.js” displayName=”msdyn_talkingpointsloader.js” solution=”Icebreakers (” /><Dependent key=”125″ type=”60″ displayName=”Contact” parentDisplayName=”Person” id=”{1fed44d1-ae68–4a41-bd2b-f13acac4acfa}” /></MissingDependency></MissingDependencies>


You only have a few days’ notice and you have no ability to control when patches are applied. Some Dynamics instances were on one version and the others instances waiting for the patch to be applied. This can create solutions which can’t be imported into some of your instances. You must monitor when patches will be applied and check if all your instances have had the patch applied.

The documentation surrounding patches is sparse and there can be significant changes. There is a risk of a patch breaking customisations in production — with a small time to test, how do you mitigate this problem? If Microsoft gave a detailed list of the changes it would help to risk assess the patch.

When I worked on projects using Microsoft Dynamics CRM on premise, the best practice was to never take the latest patch but install the patch before that. This way you could buffer yourself from Microsoft breaking Microsoft Dynamics. I wrote a blog post on it Should you keep up with Microsoft Dynamics CRM release cycle?

Microsoft could implement the latest patch to be a beta version and make it operational or move to a monthly release schedule.

In the past when patches broke production, the infamous patch of Microsoft Dynamics CRM 2011 patch 12 — where Microsoft changed how JavaScript worked and broke many instances. I discuss it CRM 2011 — Things learnt when reviewing Javascript code on form loads


Most of the times patches come and go, fix bugs and no one notices. It’s good that Microsoft regularly fixes bugs — that benefits its users. If Microsoft could improve its documentation, give more warning and make significant changes in more significant patch numbers this would resolve many of the problems. This is the online service world we live in and it’s a more exciting way of living.