So here’s a quick intro to myself and why I decide to start blogging.
I came into the world of IT and computing fairly recently, in fact, my move to work professionally in technology was through Dynamics 365(D365) or CRM as it was then known.
All sorts of things were new to me, project management, development approaches, and yes, good practice. Most of the approaches and methods I learned about were predicated on one of two scenarios: fully bespoke development, or commercial off the shelf software. Very few approaches and methods seemed to fit that well with a low code solution. When I continually asked why we were taking a given approach, it wasn’t because I was being naive or didn’t “get it”. As I was coming to D365 without having previously used these approaches, it was a bit clearer for me to see when maybe they weren’t working so well
As I have gone on in my career, I have found three constants. Firstly, those of us who work with D365 day in, day out are well aware there are ways to use the system that just make our lives easier, and when asked would almost always reply “of course, that’s just good practice”. Secondly, that when working with people who have not worked with D365 before, they don’t always want to take our word for it, and prefer to go with documented approaches, regardless of how well they fit a low code solution. The third constant links these together, as a community we aren’t the best at publicly documenting good practices.
Yes there’s lots of information and tutorials on how use different aspects of the system, and how to achieve specific outcomes. In true Microsoft style, there’s normally a dozen ways to meet any given requirement. However, for each given approach, there is little discussion about whether we should use it or not.
So here we are, this blog is my attempt to help spread the word about good practice. Whilst some of it may come across as quite prescriptive, most will be around how you can develop good practice in your own teams, and what things you should consider and have in place.
I will do a more through introduction in the future, but I didn’t want to merge my introduction with my first post, but neither did I want my blog to appear with little or no context.
Future topics may include:
- Difference between Must and Must (Also known as the difference between Should and Should
- Managing Environments and Releases
- Putting it back to out of the box
Given that everything I know I learnt from Star Trek, my blog will be starting with a two-parter Part 1: To customise or not to customise, that isn’t the question will be out on Wednesday.
That Queer 365 Guy 