I started working with Navision in 1990 and since then I've done almost everything in this industry.
In 1995 I started the Dynamics User Group, formerly Navision Online User Group and Microsoft Business Solutions User Group. Here on my blog I write mostly about the Dynamics Community, my experiences with Microsoft and especially the Dynamics NAV and Navision projects I'm working on, but also how it is to work as a self-employed Navision freelancer, Navision contractor or whatever you call it.
Ever since the release of the three tier model with version 2009, Dynamics NAV has been running on C#. Internally and partly hidden. But it is C#.
And ever since the rumors has said that Microsoft would drop our “beloved” Object Designer and replace it with Visual Studio.
Except for the Report Designer, which partially is using Visual Studio to design the layouts of your reports, then there is no indications from Microsoft, that the Object Designer will be replaced by Visual Studio any day soon.
But the question is still interesting.
Should Microsoft replace the Object Designer in NAV with Visual Studio and a full blown C#/Visual Studio experience?
If we assume that Microsoft will solve the issues described here in Mark Brummels blog post, would it then be a good idea?
Personally I think not.
What is and has already been the strength of Dynamics NAV is its “beauty of simplicity”. Even though this old “slogan” from the days of Navision Software is no longer used, then it still describes the product fully. Despite the development environment is no longer as simple as it was in the mid-90’ies, then it’s still quite easy to learn. Even for “non-programmers”!
And I think that this is one of the reasons why Dynamics NAV has gained the success it has. It has allowed companies and partners to hire people without an actually programming background and successfully turn them into great NAV developers/consultants. The structure and code in NAV is simply easy to learn and use. You don’t need too much of a developer background to add a new field, apply some new business logic or what ever you need to do.
I have always said that I would rather learn an end-user (who already understands the business logic and and processes) to develop in NAV, than take a “real programmer” and learn them to develop in NAV. Processes and business logic are more important than actual programming skills. It’s more important to get a solution that does what the users needs, than having some beautiful streamlined code. Functionality is more important than the platform.
With the arrival of DotNet interoperability, web service consumptions and more advanced integration to 3rd party application. We, the old fashioned C/AL developers, are met by a large wall. Now the “real development skills“ are suddenly required. We can either learn C#, or we have to find less beautiful ways to do the same things from within NAV (often not possible at all).
So it’s no longer an either-or. Right now most parts can still be done in the “Development Environment”, while more and more needs to be done in Visual Studio.
I cannot see how Microsoft would be able to replace the “beauty of simplicity” in the “Development Environment”, with a full-blown Visual Studio-experience. But I do read the signs.
So my suggestions to all NAV developers is, that you better start learn to use Visual Studio and C# now, or you will stay a dinosaur for ever.
A good way to start is to study Mark Brummels blog series, starting with Dynamics NAV in C# - The Differences.