The quality of your work is related to the standards you set yourself #HoskWisdom
Don’t just go to work and do just enough, take pride in your work, improve your skills and create solutions you are proud of. Working on IT projects is an opportunity to help users of the system and their customers.
Are you a Craftsman?
When interviewing developers I like to ask them if they are Craftsmen or developers, this question finds if the person being interviewed is driving the quality of their work, if they have pride in what they are creating.
Creating quality code like motivation comes from within and can’t be forced using standards or rules.
Dynamics developers need passion — Developers need Passion becuase this drives you
It‘s importance to keep the quality of Dynamics projects high and manage technical debt, these principles are even more important for 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 recommend this book
I recommend a few other books in the post — Why isn’t code reused in Microsoft Dynamic CRM projects?
My experience of Dynamics development
I started out as a Java developer and learnt traditional programmer principles. Learning about programming and I remember being inspired 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 featured in a magazine and was a regular column. It talked about problems newbie programmers walk into without realising. (called something like the woodcutter or craftsman)
When I moved from Java/.net development it seemed many Dynamics development didn’t follow good software development practices or good coding standards.
- 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 made it difficult for automated builds (before solution packager)
- Companies were not interested in invested in
- Many projects were small with no budget for automated builds and unit testing
- developers had no knowledge of SOLID principles
- Timescales were short in projects — focus on short-term gains
Dynamics and developer principles
Enterprise projects are long , technical debt must be controlled and members of the development team implement high standards (high standards are a habit) Here are some methods to keep quality high
- DevOps helps bulid regularly and takes the boredom out of development
- Automated deployments/CI environment
- Solution packager can import data
- Solution packager splits up customisations to XML file and stored in source control
- Code reviews
- Static analysis on code
- Minimum 90 percent unit test coverage on Business logic code
- The Quality code message comes from the top
- Implement high standards
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
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 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 project using software principles.