Developer Viewpoint -JavaScript and Dynamics 365

When you need to innovate, you need collaboration. Marissa Mayer

Developer Viewpoint is regular section on the blog a section that involves two developers discussing an issue. The discussion takes the shape of a dialogue and in this issue, Ekhor Asemota discusses JavaScript and Dynamics 365 with Zoe Dawson.

Ekhor is an experienced Microsoft developer with experience in DevOps processes for Dynamics 365

Zoe is a Microsoft Dynamics CRM Consultant within the Microsoft business unit. She is a highly experienced software engineer who has worked in several industries using a broad range of technologies such as C#, ASP.NET/MVC, JavaScript and multiple versions of Dynamics 365. She also finds time to encourage women participation in IT through the Women In Tech and The Prince’s Trust organisations.

Ekhor: In a previous assignment, we both worked on a Dynamics 365 delivery and I was very impressed with your mastery of JavaScript. What were the factors that made you learn this language which many software engineers dread?

Zoe: Initially it felt like the easiest way to sneak myself into a development role. In projects where I was put on testing, it was far easier to try and convince someone to let me do a small piece of JavaScript functionality in a spare half hour than to be allowed to do a whole day of plugin development. Then when I started being put on development roles, I was already far quicker at JavaScript than C#, which was something I had been taught before joining Capgemini, so would pick up JavaScript tasks to quickly get them out of the way. From this I realised that JavaScript isn’t actually that bad, yes it’s mostly odds and ends of functionality; but there are also opportunities to make more complex things. I think one of the reasons JavaScript isn’t that appealing is that it’s used for all the simple things like showing and hiding fields, which isn’t really that impressive to most people. It’s far easier to be proud of a plugin that provides all the functionality you could possibly want than two lines of JavaScript that show and hide fields.

Ekhor: Despite the love or hate reputation which JavaScript has with many, it is everywhere and as software engineers we can’t really ignore it. What would be your recommendations for a software engineer who wants to become competent with JavaScript?

Zoe: Personally I’d recommend not just forcing yourself into an online JavaScript playground where you have to change the colour of buttons and make simple calculators; because, assuming you’re not really excited to learn JavaScript, these things aren’t going to feel rewarding or useful. I found it far easier and more engaging to learn when it was for something more important, for example for a client or side project. I’d start by picking up JavaScript tasks you either don’t know how to do or you think would be interesting, or ideally both. Having a real reason to use JavaScript, like auto-populating Dynamics CRM fields for a user story or setting up website navigation functionality will hopefully make people feel that learning JavaScript is worthwhile.

Ekhor: Dynamics 365 uses a lot of JavaScript and it is an area where you have a lot of experience. This platform is currently very popular. Why do you think many clients are selecting this platform instead of bespoke .NET solutions?

Zoe: I think people might find it scary to throw money at something they can’t see. With bespoke solutions, realistically you could get anything; you hope you’ll get what you asked for, and something similar to any proof of concepts you’ve seen, but I think there’s always a fear that clients will end up with something a bit different to what they wanted, even if it technically ticks all the boxes. With Dynamics 365, you can only stray so far from what comes out of the box; the method of navigation is always going to be similar, the forms will always look similar and the look and feel of the solution in general won’t be all that different from any other Dynamics 365 instance. To me it seems like this very big, expensive safety net, that means developers can’t run too far from what the client is expecting. I also think this can be a very bad thing; it seems as though some clients are so excited to already have this application before development really starts that they pick Dynamics 365, when in reality they want something completely different, but don’t want to wait to see what .NET developers can give them. This results in a Frankenstein creation that is trying really hard to not be Dynamics 365, and results in neither the client nor the developers being happy with it.

Ekhor: Do you think there are enough opportunities for a .NET software engineer within the Dynamics 365 space?

Zoe: In every project I have been on, even with them all having a customisation-first approach, plugins and C# development have always been required. I think as Dynamics 365 evolves and is updated with new features, a few things that are done as standard in plugins will no longer need code; but from my experiences in the Dynamics 365 space I think there will always be something for a .NET software engineer on Dynamics projects, even if not necessarily a reliable amount of work.

Ekhor: Without going into client specifics, what types of solutions have you worked using the Dynamics 365 platform?

Zoe: Most of my work has been either CRM 4 or CRM 2011 upgrade projects, requiring migration to the latest version of CRM, whatever that is at the time. I have also worked on some upgrade projects where complete redevelopment was required, due to all of the changes from CRM 4 to Dynamics 365. Although the upgrades have been simpler from the point of view of meeting client requirements — it should just do everything the old system did — I have found the new development projects far easier in terms of implementing the functionality as it is meant to be in the latest version. The issue with upgrade projects is what may have been a perfectly good idea in 2007 when developing a CRM 4.0 solution, does not necessarily translate into a good idea in 2019, when migrating to Dynamics 365.

Ekhor: What would be your recommendations for any software engineer who wants to become competent with JavaScript and Dynamics 365?

Zoe: I think the best way is to get a trial instance and make up some requirements to build something from. I definitely learned far more from even just a testing role for a Dynamics 365 system than revision notes for the Customisation and Configuration exam. Once you have some experience with using Dynamics, I think for going into JavaScript it’s to play around in the Chrome developer tools, and try and hide, populate or clear all of the fields on a form in your instance. I think the next most useful thing to know how to use is the Web API. I would get a query function working that returns records in the way you want them, and then save that somewhere handy, because it’s so much easier to just copy and paste that when you need it than having to remember all of the different request header parts you need. I found the Dynamics 365 documentation really useful for checking any queries, because the majority of the time the only thing breaking my query is a missing apostrophe or ampersand.

Ekhor: Which areas in the industry are you currently focusing on?

Zoe: I keep telling myself I’m going to get into Azure work, because I’ve been studying for a certification in it and I find it really interesting, but I don’t have any work based experience in it and I also have a lot of uni work to do before I finish in August, so I don’t think I could give it enough of my time at the moment. I’m happy sticking with the new updates to Dynamics 365 and JavaScript at the moment, though I have some mobile development in Java/Android Studio planned for my dissertation if I get my idea approved.

Read previous Developer viewpoints