Microsoft Dynamics NAV Extensions – Concerns (2/3)

This is the second “leg” of my “Extensions”-series, where I want to address some “concerns” I hear sometimes regarding Extensions. If you haven’t read the first one, here you can find it.

First a disclaimer: I don’t know about all concerns, but there are a few that I picked up, which I tried to summarize in the below

Why can’t I see the code?

This is one I get a lot. Basically, the problem many people have is that they cannot code against Extensions. And it’s kind of true .. . At least in the current version of Extensions. Just because the fact that your object designer doesn’t see anything of the Extension. So creating reports based on fields that only exist in an extension .. that’s going to be difficult.

Difficult, because it IS possible. The only thing that you need to do is to create a dependent extension. One caveat: you still need the code of the extension you want to create a dependent extension for. So you ARE able to change the behavior of an Extension – you just need the actual objects, and not only the .navx file.

Well – then it’s up to the ISV, right? Are they willing to give you the code? I had to do this once .. asked the ISV .. created my dependent extension (with legalizations for Belgium) and we were good to go.

But I understand not all ISV’s are eager to give you the code .. and then, it’s not that different then we have now – as ISV’s are already able to “protect” their code with the license .. . But let’s keep that for the next section.

And let’s not go into the “Open Source” discussion – NAV is not Open Source.  It never was.

My assumption (not based on any info I have from Microsoft) for the future is that this might change. When you think back about the reference model I talked about in the previous post. Well .. we might be able to get those references as well to our VSCode DEV environment. I mean – who knows – why not. The code is still protected, we would just be able to code against it.

The code is protected, right?

The previous concern is about developers. This one is about the ISV, which has conflicting concerns :-). ISV saying “my code is protected, right???”, and developers saying “I can get to the code, right???”.

My opinion: Why bother? I don’t think your IP is in the code. It’s merely a way to “store” your IP. Your IP is in the (industry) expertise.  You power is not the ability to write .. but the ability to translate – translate the IP into business logic.  Code is just a tool. Nothing more. I never cared about other people being able to read my code. I put it on github for crying out loud! 😉

And as said earlier, this is not so different as what we are used to. I was never in favor of this, but people have been “masking” their code, like this download on mibuso. I even have seen partners scrambling their code into unreadable variable names and such .. go figure :-/. And of course, there is the license, that can prohibit you to go into design of an object.  The one and only right way, in my opinion.

So, is there no way to get to the code of an Extension? Actually, yes. I’m aware of tricks to get into the code of an extension. As I’m aware about tricks to get into the code of an object that is not licensed in a normal development environment. So .. also no changes there .. we have been able to do this for years. Just different ways to do the same. Both illegal, by the way ;-).

“You can do bad things with Extensions .. or you can use it in the wrong way.”

Well, isn’t this with about every development feature/language/environment? Just think back at what Spiderman’s uncle said: “With great power comes great responsibility“. You, developers, have great power!

I can hack with PowerShell .. does that make PowerShell bad? I can write “Format c:\” in a shell – does that mean I have to remove the command shell?

This is why we have Best Practices.

This is why there are Design Patterns.

This is why we have Education.

Extensions is still no solution for upgrades

Wrong!

But let’s first take a step back. On any system that upgrades from A to B, software needs to be revised.

• Whether it’s apps
• Whether it’s just software
• Whether it’s a website
• …

Just a few examples:

• If you upgrade your phone, the apps usually start upgrading as well very shortly after. These apps have been updated for the new version of your Phone’s OS
• I just upgraded to the newest build of Windows, well, my display adapter didn’t work anymore .. it needed an upgrade. And guess what – it was already available.
• When there is a new version of explorer, some (parts of) websites might not work anymore.. .  This happens all the time..
• …

An Extensions “extends” something – so if you break the thing that it is extending .. well, sure you have some work! This is what I believe is called “maintenance”. Quite common in “software development”. So if you think that you write an Extension, and you don’t have to look at it for the next decade .. then you have the wrong expectations from any kind of software, not only Extensions.

Yes, but “in the old days”, we could at least choose to stay on an old version..

Could you really? Because many countries very regularly come with new legislations .. which HAD to be implemented at some point in some way, else, you would just be as illegal as can be. So maintenance was needed as well!

Does this mean that Extensions will not help us in upgrades at all?

Sure they will. I believe that in 99% of the cases, they will be able to upgrade without any problem. Why 99%? Because at any upgrade I do now (which is classic, nothing to do with Extensions …), I can upgrade 99% of my code without conflicts. And extensions are far better in this  .. one reason is because they don’t touch code at all! Remember we probably need to rethink our code to facilitate Extensions. This is where you’ll see the benefit!

There are just a few scenarios where you need to rethink your solution, like:

• When new functionality in an upgrade version of NAV can replace your extension. Although – they probably can co-exist.
• When Microsoft redesigns a part of a solution. Even this doesn’t need to be that big of a problem. I’m upgrading to NAV2017 at the moment, and thanks to the hooks pattern, the big redesign of CU80 isn’t that much of a problem. Decent code design always helps. And in case of extension, you would have been using events anyway .. so that’s even less of a problem.

What I would suggest for Microsoft (this is again a personal suggestion, not based on any info I have from MS) is to make the Testability framework a mandatory part of Extensions. Then at least, Microsoft or whoever does code-redesign or upgrade the base platform would have two basic steps to test whether there might be a problem for Extensions:

• Does the Extension still install (and compile)
• Does all business logic still execute as expected

If not – contact the author (probably the author was already informed about an upcoming upgrade and he is already working on it.. (like my display-adapter-driver-guy did)), who has a contract that he needs to provide an update in a certain amount of time, and let him fix it!

Do I have to change? Can I keep developing in C/SIDE? I’m a dinosaur – I don’t want to change

In NAV2017 you can do whatever you like. You can do Extensions only, or customizations-only .. Or even mixed mode (which I don’t think is a good idea ;-)). I can’t talk about the future .. I don’t know what you will be able to do and what not. I do know that Microsoft is “all in” for Extensions. As am I. I’m looking forward to the day that everything is in place … I really do. When – not “if” – I will be able to do custom development by solely Extensions, I will be a happy man ;-).

So, yes, at this moment, you can do without. But because competition will become faster and more cost efficient, they will soon be more competitive .. and if you still need to start the extension work and repeatability work then, it’s going to be hard to catch up!

Will classic On Premise NAV die eventually?

This concern is not directly related with “Extensions”. But “Extensions” is obviously very much to do with Dynamics 365. And apparently some people have the feeling this, in a near future, means we won’t be doing classic On Premise implementations anymore.

Wrong! NAV will stay. On Premise will stay. Microsoft will keep supporting partners doing that.

But make no mistake. The market is shifting. Microsoft gives you a fantastic product to shift with it: Dynamics 365. And it is obvious that this gets priority. That means: Extensions, Web Client, .. and everything that can leverage it. To quote Marko: “The wind is blowing towards Dynamics 365”.

All my developers have so much knowledge. Will that be wasted?

You know, one of my favorite quotes is one of Bill Gates: “IT knowledge has the shelf life of bananas“. In my eyes, a good developer is not the one with years of experience, or tons of knowledge. I even dare to say that “too much” experience and knowledge can hold a developer back .. .

In my opinion, a good developer is not only someone who is capable to thinking logical .. but more important, he or she is someone that is able to adapt. A “best practice” of today might be a “worst practice” tomorrow. That’s what is called “evolution”. And a good developer is able to see this and evolve with it.

And this doesn’t even only apply to developers only. Same for consultants, same for marketing .. same for any IT business.

Just my 0.02€

These were my views on some “concerns” that I picked up. You know, sometimes people just put “concerns” out there to try to prove that something sucks – while it is actually just marketing: “look how much it sucks, let me fix it for you .. “. Always take opinions with a decent pinch of salt (especially mine 😉 ).