Microsoft Dynamics code and customizations are rarely reused between projects and few companies create solutions to share between projects. This means companies need to rewrite the same code again for each project but is there an alternative method.
Dynamics projects focus on delivering solutions but don’t to reuse solution and code. In many companies Dynamics developers can create different versions of the same solution.
When developers work on projects they are focused on delivering a solution to meet the customers requirements. If time the developer will
- Improve code design
- Refactor code
- Reduce technical debt
- Unit test code
- Update documentation
The tasks mentioned focus on long term benefits and the reason they are often omitted. Improving code design and refactoring make code easy to understand, extend, debug and maintain, these steps are unnecessary but make a huge different in maintaining the code.
The difference between good and average developers can’t be seen in functionality delivered to the customer because they will be the same.
It’s difficult to code, refactor and improve the design, a reason average developers omit those steps. Explained beautifull by Martin Fowler
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand“.
Simple code reduces time spent debugging, maintaining, understanding and interacting with the code e.g. further phases of development. This explains why failures in projects often occur after the first release of a Dynamics solution when the developers struggle with a messy solution.
Other signs you Dynamics project is doomed can be found in this article 13 signs your Dynamics project is doomed
I have worked on a project where a plugin had a method was over 1000 lines long. This method became a bottleneck in the project because developers struggled to understand what it did or how it worked.
Small changes took hours whilst developers tried to understand the code, work out where to put their fix and testing the fix hadn’t broken existing code was impossible because the code was to complex to unit test.
Most Dynamics projects will have custom entities which exist only in the individual project to either make the customers business processes or needed to deliver the required functionality.
Writing bespoke projects often prevent the project code and customizations being reused because the customers requirements are not needed in other projects.
Dynamics developers who don’t use solid principles to reduce coupling in their code are unlikely to reuse code.
Code cannot always be reused because of unique requirements, most of the time CRM developers don’t think about reusing the code or writing it to enable reuse.
New project, new code
“Before software can be reusable it first has to be usable.”
– Ralph Johnson (computer scientist)
Reusing code adds code which has been tested. It takes more effort to write reusable code, to write code in a generic way ensuring there are no dependencies on the current project.
Developers are not rewarded for code reuse or encouraged to write reusable code and customization’s by their employers. Without motivation or reward why would developers go to the extra effort of writing code which benefits developers/company in the long term?
To write of reusable code you need skilled developers, sometimes called craftsman. Highly skilled developers, take pride in their work and consider long-term implications of their code and who look to reuse code.
Most Dynamics projects are run with short-term goals in mind, answer these questions about Microsoft Dynamics Dynamics projects you have worked on?
- How often do developers reuse code from earlier projects?
- Do developers know what earlier projects did to understand if code or customizations could be reused?
- How many projects is the code good enough to be reused?
- Does anyone look at previous projects to see if they could create a generic reusable project?
Companies don’t reuse code or catalog Dynamics projects. Dynamic developers move companies, most existing and new developers didn’t work on earlier projects and are ignorant of them.
Interaction with historic projects occur when a bug is raised or through a change request. If you are unluckily enough to be dragged into an old project, they are legacy projects with code and customizations arranged in a baffling structure taking days to decipher even the simplest of bugs.
Is there another way?
Wouldn’t it be great if new Dynamics projects were created by plugging together small separate solutions. It would be quicker to create solutions like this and the code would have already been tested.
Dynamics developers could look at old projects for common functionality that could be reused in different projects.
Identifying functionality which could converted into a generic reusable solution. It could speed up development on new projects needing that functionality.
Why doesn’t code get reused
Code reuse has many advantages but I haven’t seen any examples of code reuse in the projects I have worked on. I have listed some potential reasons for this below.
A lot of developers don’t love writing code and to them it’s just a job, this shows in the quality of their code. They are not passionate about it and certainly wouldn’t classify themselves as craftsman. I don’t enjoy decorating, I take shortcuts and aim to paint a room as fast as possible. The lack of enthusiasm and passion for decorating the room, shows in the finished product, I spot bits I missed and drip marks.
The same result can happens with the code of people who don’t enjoy developing,
To write simple code you need to want to improve, the best way is to have a mentor but you can get a paper/electronic mentor by reading classic books on programming or have a mentor to teach you. I recommend
- Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
- The Pragmatic Programmer
- Code Complete: A Practical Handbook of Software Construction
- Refactoring: Improving the Design of Existing Code (Object Technology Series)
Companies have a high churn rate, offering small payment increases to staff based on their current salary. LinkedIn pressures this model with recruitment agencies offering Dynamics professionals the current market rate for their skills and experience, more than the current salary plus inflation.
The regular movement of CRM developers leads to a lack of long-term thinking and planning. Why write code with long-term benefit if you are not going tto gain from it.
Development standards and way of working need a consistent workforce to implementand developers adhere to them.
Dynamics solution providers organise effort at a project level, gearing everything around projects. The approach is understandable because customers pay for projects.
Creating reusable code and solutions is an activity which needs to be done around or outside of delivering a project. It may involve going back and identifying reusable/generic solutions or taking a longer to write reusable code.
Upgrades and version
Microsoft Dynamics currently has a major release every year, this adds a significant challenge to creating reusable solutions and code.
A solution created today could become standard functionality in the next release of Microsoft Dynamics or your solution might not work, with a need to upgrade the solution to be compatible with the new versions of Microsoft Dynamics.
It’s easy to point out the problem of lack of code reuse, it’s harder to pinpoint the steps to overcome this.
The project mentality creates project focused code, not reusable or often known about by other developers in a company.