Are you a Dynamics Craftsman or a CRM developer?

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

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

 

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

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

Are you a Craftsman?

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

• Definition of Software Craftsman
• Don’t be a Software Developer, be a Software Craftsman

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

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

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

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

I can recommend the book

• Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

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

My experience of CRM development

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

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

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

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

There are a few reasons for this

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

Dynamics CRM and developer principles

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

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

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

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

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

Regrets I have a few

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

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

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

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

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

You can join the Hosk at Capgemini by applying here

The Fairy of failure – Who broke the build

But man is not made for defeat. A man can be destroyed but not defeated. Ernest Hemingway

One of the reasons I am enjoying working for Capgemini CRM team is the projects have a DevOps team and we have continuous integration. It’s so awesome to have check-ins triggering automatic builds which verify your check in has not broken anything.  Quick continuous feedback gives confidence in the validity of the CRM solutions.

Continuous integration

We have lots of builds being regularly kicked off and we have regular builds to move the latest code into the CI environment, enabling us to test our code in a shared environment.

The more often you build the quicker you find problems and with smaller changesets

The Devops team have created dashboards for the different scrum teams, allowing the development team to check the build is good and the build is green.

You may notice we have gone for the solution structure of customisations, plugins and workflows.  Which is the solution structure I prefer, which I have discussed in this post

CRM 2016 – What’s the best way to organise solutions in Microsoft Dynamics CRM

Build breakers

When you have a lot of builds you have developers who break the build.  These build breakers must be publicly shamed.  Making mistakes when you are trying new things is fine, often mistakes are caused by bad processes and systems – take ownership for what you do

Mistakes caused by laziness need to highlighted so the team knows someone has been slacking at work

Many developers are asleep at the keyboard of development #HoskWisdom

To help with the public shaming of build breakers I have brought in the fairy of failure which gets awarded to the developer who

• Breaks the build
• Makes a schoolboy error
• forgot/couldn’t be bothered to do something

It was the fairies first day today and she has already been sitting on two different developers monitors and it was quite amusing shouting FAIRY at a developer today.

If development isn’t fun, you are not doing it right #HoskWisdom