Thursday, October 31, 2019

Pushing, Dragging or Pulling an Industry Forward

Quite a few years ago, in my previous job when I was an MVP still, I did an online webinar for the AXUG called "Putting Software Engineering back in Dynamics AX" (in 2014). Admittedly it was somewhat of a rant / soap box type of talk. I guess "food for thought" would be a more optimistic characterization. I did try to inject some humor into the otherwise ranty slides by adding some graphics. At the time we were building out our X++ development team and we were heavily vested in TFS and automation, and I was very keen on sharing our lightbulb moments and those "why did we only start doing this now" revelations.

Fast forward 5 years to a new generation of technology and a shift to cloud. In fairness, many more people are engaged in some of these topics now because the product finally has features out of the box to do builds, use source control without tons of headaches and setup, etc. But contrary to the advice on one of the original slides from 2014 that said "Bring software engineering into AX, not the opposite" - it sort of feels that is exactly what has happened. People projecting their AX processes onto some software engineering processes. Sometimes ending up with procedures and technology for the sake of it, and not actually solving any problems at all and sometimes even creating more problems. But, they can say they ticked another checkbox on the list. I have stories of customers with messed up code in production, because someone setup branching because they were told that's a good thing to have. Yet nobody knew what that meant or how to use it. So code was being checked into branches left and right, merged in whichever direction. Chaos. A perfect example of implementing something without having a good reason or understanding to do so. On the flipside, we have customers calling us up because they "redeployed" their dev VM, and want to know how they can get a clean copy of their code from production back into their VM. Now, part of that is legacy thinking and not understanding the technology change. But honestly that was never a good thing in older versions either.

Anyway, that brings us to my topic du jour. As you may or may not have heard and read, we're working on elevating the developers tools further. We'll become more standard Visual Studio, standard Azure DevOps. This is all great news as it will allow X++ developers to use more of the existing tools out there that can be used for any standardized .NET languages or tools. The problem is not that we'll be forcing people to use advanced tools they don't know how to use. They can still choose to not use source control or build automation. I'm more worried about the people using all these new tools and not understanding them. What if in the future we start supporting Git? Will our support team be overwhelmed with people stuck on branching, merging, PRs, rebasing and all the great but complex features of decentralized source control? We've never dealt with situations where we "support" the technology (i.e. the tools are compatible) but we won't support the user of that technology (sorry your production code got messed up, go get some training on Git branching and good luck to you on recovering your production environment). In the history of our product, we've never drawn a big line between technical compatibility but not supporting the usage of it. But we will have to. How about other areas, like PowerBI, PowerApps, etc.? Yes they are supported and will be integrated further, but will Dynamics 365 support answer your usage questions?

I've had frank discussions with developers (that I personally know), where I basically tell them "the fact you're asking me these questions tells me you shouldn't be doing this". But that's not an attitude we can broadly apply to our customer base.

So I ask YOU, dear audience. Where and how can we draw a line of supportability?


  1. We use Git for D365FO at my job. It's been a pretty decent success, albeit a large learning curve for most developers. The more AX-specific a developer is, the bigger the learning curve; we've had to adjust expectations on upstart time, and changed how we intake code from consultants, but it's worked well in general. Git is used almost everywhere else in the industry, so most non-AX developers come with that minimum bar of knowledge. X++ devs will get there in time. It'll take time for expectations to adjust, once more AX devs use Git for their project workflow.

    I personally believe Microsoft is on a good path to enabling developers. Don't require Git. Don't provide basic support for it. But do architect the underlying application to simplify its adoption for developers. Moving framework libraries to Nuget, separate command line tools for compilation, simplifying CI/CD (hosted builds), support for modern versions of Visual Studio (2017+) - these all move us in the right direction.

  2. Depends on who do you ask for:

    If you are a partner implementing F&O probably you care more about the functional part rather than development withing 'AX' - because of that we have more 'non tech' people driving the implementation rather than technical. - these guys would see any change (supporting git, build server, CI/CD) as a cost and a way to make implementations more slow / expensive.

    If you are an ISV with X++ and C# - probably the C# guys are "mocking" X++ guys because we have no generics, no git support and no real mock framework for unit test. In AX world, if you talk about unit test, very often you get the answer - no, we don't have time. How likely is for this technology to attract strong tech people?

    The approach used by LCS (do everything from UI, hide azure because is a saas, do everything from LCS instead of using Azure DevOps, not providing a API to support automation) is also a barrier to bring more tech people to AX.

    I think the right balance is:
    - make it clear! if you want to develop to AX you need a software developer. If you don't want to develop in your implementation - buy an ISV solution for your functional gap.
    - support the essential (GIT, build, CI/CD, API for LCS), but not being disruptive. If you don't know what a branch is, don't use it!

    I get your point - but if we don't empower developers, each day we will have less and less high skilled devs, and more "citzen developers", spamming the support with silly incidents.

    Where are we going? Are we going to a model where a functional can do everything (low code - no code) or are we empowering the developer (support git, test automation, mock framework)?

  3. I like where things are going from my perspective.

    In my oppinion the Dynamics 365 team should only have to support the product itself(hotfixes, releases, platform updates, extensibility), build capabilities(scripts) and tools for development(Visual Studio + Plugin).

    The One-Version is a great way to put a boundary on support regarding the product, hence I think an ISV should follow and do the same with their customers. It's great if an ISV wants to use an older version of the product. However, Microsoft should't support it. New development is done on the latest version provided by Microsoft as they are the leading developer and an ISV should follow.

    An ISV should decide if they want to use GIT/TFS, or any other platform, or no source control at all...
    They are responsible for their product which they deliver to their customers. This way Microsoft provides the freedom an ISV needs/wants.