The future of NAV developers

einsTeIn.NET · 2011-10-04

Hi guys,

I want to refer to a question that was asked at the NAVTechdays 2011 and about that I also thought in the last few month. It was the first question in Christian Abeln session and I think Christian didn't give a proper answer to this question. I mean from a certain point of view this is the only answer someone from Microsoft could give. But there's also some truth in what you could read between the lines of this question.

In general the question was about: What kind of methodology does Microsoft (or someone else) provide to qualify traditional NAV developers so they get used to the new possibilities of .NET? An NAV developer should know something about databases, table relations, business logic and so on, a .NET developer lives in a complete different world. That maybe will cause some problems in future. I'm sure this will not happen in every situation, because there are some specialists that are able to live in both worlds. But there is a certain risk if you hire an NAV developer that your solution doesn't consider all possibilities of new technology and on the other hand if you hire a .NET developer that not all NAV database issues are covered.

From my point of view this question also implies the following: What will be the future of NAV developers? You know SQL becomes a bigger topic in future, web services as well, form and report design is going to change, maybe cloud computing and network could be an issue,... I think maybe it's possible that we won't have a single NAV developer but several for different parts of NAV. And that leads me to another question: From a companies point of view, how should someone decide which way to go with his traditional NAV developers? I mean NAV is not a development tool, it's an ERP system with some possibilities in development. So, you need someone who knows about the business logic, not so much about the programming language (that's easy to learn for someone who's able to program). That means, should you qualify your current developers in terms of .NET or should you hire .NET developers and teach them how to understand and implement business logic?

You see, I have some doubts about the right way and there're plenty of open questions about the future. So, I want to hear what you guys think about that...

David_Singleton · 2011-10-04

Interesting topic. I wasn't at that session, so I didn't hear that question, but...

I am writing a series of blogs for the Dynamics community
https://community.dynamics.com/product/ ... ystem.aspx

And in preparation for the next one I was pulling some ideas from an old blog I wrote but never published exactly about this topic. Not so much a coincidence, as this being quite a hot topic. Of course I need to focus on my blog right now, but in summary.

I don't see an issue here. Right now the shortage of Skilled NAV developers is probably even more acute than when we had the huge shortage between 1996 and 1999. Its nearly impossible to find skilled NAV people right now, but since there are literally 100,000 of .NET and C# etc programmers, it seems only logical that those skilled in NAV need to stay where they are and if anything hone their NAV skills rather than learning new stuff.

Keep in mind that one of the highest paid techies out there is the Developer skilled in DB400/Cobol/REXX etc. :whistle:

einsTeIn.NET · 2011-10-04

David Singleton wrote:

Right now the shortage of Skilled NAV developers is probably even more acute than when we had the huge shortage between 1996 and 1999. Its nearly impossible to find skilled NAV people right now, but since there are literally 100,000 of .NET and C# etc programmers, it seems only logical that those skilled in NAV need to stay where they are and if anything hone their NAV skills rather than learning new stuff.

Keep in mind that one of the highest paid techies out there is the Developer skilled in DB400/Cobol/REXX etc. :whistle:

I see what you mean. But you also know that even in this shortage it's difficult to find a skilled NAV developer. Some guy typed some lines of C/AL and calls hisself an NAV developer, you know what I mean. In future you have to choose between a lot more candidates and I'm sure there're also many that are not skilled in the way you want them to be. That doesn't make things easier.

And it's true that DB400 developers are best paid (doh, while my studies I should had gone that way

). But their workload could become less and less because those systems become less. Ok, those developers also become less and maybe it's still enough work for a lifetime, but may not in a certain region or branch. I don't know exactly, but I know it would be hard for a DB400 developer aged 55 or maybe 60 for example to change his whole life and maybe he won't get a new position if he needs to. I mean I wouldn't want to keep my developers in a position where they maybe will have problems in future to find another job.

einsTeIn.NET · 2011-10-04

David Singleton wrote:

I am writing a series of blogs for the Dynamics community
https://community.dynamics.com/product/ ... ystem.aspx

Right, that topic in some parts points also into the same direction.

kine · 2011-10-04

I do not see any problem here. Main thing is that you will need more developers for different topics.

*NAV Developer doing the business logic inside NAV, preparing webservices for outside
*C# or any other developer to create the application consuming the webservices (or creating webservices consumed within NAV), creating addins for RTC...

And if you have these two, the C# developer could help NAVdeveloper when he need to use .NET interop to do something using .NET assemblies...

For C# developer is not problem to learn the C/AL but it is problem to learn the business logic. For NAV developer it is not problem to understand logic but learn the C# (.NET). Put both into a bowl, mix, and you have team solving different things on both sides...

Of course, if NAV developer is accessible to learning, he will learn .NET quickly enough to be able to create some addins and application himself.

Hardest is to try teach NAV developers to .NET without having some .NET developer on site.

einsTeIn.NET · 2011-10-04

For sure, Kamil, that is one possible way for future. But think about a small development department. We have to buy Visual Studio, hire at least one new .NET developer and integrate him into our team. And all the traditional NAV developers maybe think about what will happen if the new .NET developer has learned to code C/AL.

Additionally that means that NAV development in future will be more some kind of team development rather than a one man show. That means you have to change the way how your department works. All the different development processes have to be reviewed.

All of that will be a massive change for a small development department.

davmac1 · 2011-10-04

We have been looking for a skilled NAV developer to join me.
Since we could not find one, management decided to hire a junior and transfer him in.
I am kind of dreading it because it is so easy to cause major problems with custom code.

The move to using more .net could make the shortage of good NAV developers worse, since I believe a good ERP understanding plus a good functional NAV understanding are requirements for a good NAV developer.
Then in addition to that you need the C/AL skills, the SQL knowledge and skills, and now the .net.

kine · 2011-10-04

The days when the process was one-man-show are away a long time. And if somebody missed that, than sorry, but the train is already moving, it will be hard to catch it.

Long before NAV 2009 was released were announced, that there will be more C#, more reporting, SQL support only etc. It is more than 3 years now. If somebody noticed it now...

That processes in partners companies must be changed - definitely yes, just because RTC instead classic, you need different processes than before. There are new tools, new ways how to solve different things etc. To install NST you need to understand how the SPNs works, thus you need knowledge from administration, to be able to use SQL you need knowledge from SQL administration etc. But all this is known long before all this, you have the Statement of directions document. Why everybody is starting to solve that just now?

einsTeIn.NET · 2011-10-05

kine wrote:

The days when the process was one-man-show are away a long time.

Of course, you are right. I didn't want to say that it should be a one man show or that a one man show is a proper way of working. I just wanted to point out that smaller development departments maybe will have to change their team structure. Or at least find a reliable and highly available way of how to analyse, modify and display business processes and business data based on the up-to-date technical possibilities. How do you get to this point and what is the best way to get there? That's not easy, especially if you have to consider your given budget.

kine wrote:

Long before NAV 2009 was released were announced, that there will be more C#, more reporting, SQL support only etc. It is more than 3 years now. If somebody noticed it now...

First of all you can't base your team building on some rumors that are in the market. E.g. there're now some rumors that in future NAV and Sharepoint will merge somehow. Should I now hire a Sharepoint specialist to be prepared if this maybe becomes true in some years? And what if plans change during the years? I mean that is not an option and I would never base my long range decisions on rumors or something that is not official.
Second point is that some informations are only available for partners. So, if you are an end-user sometimes it takes a little while to get some news. And after you get it you have to understand it and classify the consequences. Afterwards you have to make a decision in your department, create a proposal for your board, consider it in your budget and HR planning and so on and so on. You see sometimes decisions at an end-user aren't as fast as they are at a partner.
But you're right, the preparation in terms of this topic could had gone much faster. But I'm sure you also know sometimes (espacially) end-users eschew (inconvenient) decisions and postpone them several times. :whistle:
I believe that many end-users at the moment are not prepared for that (switch to RTC, modify business processes, change the way how development change requests should be worked out, think of the possibilities of new technology, ...). So, I don't want to complain about the situation, I'm pretty sure we will accomplish it. But I think it's even worth to discuss it and see what other think about it.

matttrax · 2011-10-05

einsTeIn.NET wrote:

if you are an end-user sometimes it takes a little while to get some news. And after you get it you have to understand it and classify the consequences. Afterwards you have to make a decision in your department, create a proposal for your board, consider it in your budget and HR planning and so on and so on. You see sometimes decisions at an end-user aren't as fast as they are at a partner.

How is this any different than a normal upgrade? Yes, there are more inputs into the final decision, but that's what the partner is for, to guide the end user to the best possible solution.

einsTeIn.NET wrote:

I just wanted to point out that smaller development departments maybe will have to change their team structure. Or at least find a reliable and highly available way of how to analyse, modify and display business processes and business data based on the up-to-date technical possibilities. How do you get to this point and what is the best way to get there? That's not easy, especially if you have to consider your given budget.

Again, I guess I don't see how this is different than normal. I think that's one of the main functions of an IT / Programming department manager: to do their best to stay ahead of the game, anticipate changes in the software they will be supporting for the company, and take appropriate steps. Whether that be hiring new people or sending existing people to training, those are the decisions the manager should always be making based on the current conditions (budget, work load, etc).

Obviously the NAV world is changing, and those who continue to work with it will need to change too, but I don't see how it should drastically change your process or structure. Then again I'm just a developer

Never had anyone report to me or had to really make those kinds of decisions.

einsTeIn.NET · 2011-10-05

matttrax wrote:

How is this any different than a normal upgrade? Yes, there are more inputs into the final decision, but that's what the partner is for, to guide the end user to the best possible solution.

Do you mean we should ask our partner about how we should qualify our employees and how we should do our HR planning? Ok, from one point of view they maybe had the same questions in their company some time ago as well. But on the other hand I think they won't give any reliable consultancy to this. Maybe a guess or a hint how they did it, but there are many differences between a partner and an end-user, so I don't know if that would work.

matttrax wrote:

I think that's one of the main functions of an IT / Programming department manager: to do their best to stay ahead of the game, anticipate changes in the software they will be supporting for the company, and take appropriate steps. Whether that be hiring new people or sending existing people to training, those are the decisions the manager should always be making based on the current conditions (budget, work load, etc).

Absolutly! You're totally right.

matttrax · 2011-10-05

einsTeIn.NET wrote:

Do you mean we should ask our partner about how we should qualify our employees and how we should do our HR planning?

Not at all, a partner shouldn't tell the customer how to run their company. They should educate the customer on the product, and then the customer makes informed decisions about the type of staff they need / if they need to hire new people or train existing ones.

For example, if NAV ended up moving entirely to the .NET platform, I would like to think that a customer with in house NAV development staff would not upgrade to it without determining their developers' .NET experience. You have to build on what you have now and plan for the future at the same time. This is one of the extra inputs I meant. It's important to not just consider functionality, but consider the software as a whole. Customers usually have years to plan for these types of things, that's why I don't think it really changes anything. NAV versions are supported at least two at a time, and have extended support back another version. So that's 6 to 8 years you can be on a supported product without a change to your staff. Plenty of time to plan ahead.

I know that was a bit garbled, but hopefully you get what I mean.

einsTeIn.NET · 2011-10-05

Yeah, I think I understand where you are coming from.

Keep in mind that you have to do all of this while you have to keep your normal business running. As explained earlier take two years away where you just gather information, then another two years where you think about and plan your strategy and maybe another two years where you search for a proper new developer or educate your existing ones. That means you have between zero and two years where you could decide how to go on. And that doesn't include unexpected team changes, company politics, trouble in operating business, etc.

davmac1 · 2011-10-05

The new version of NAV allows for much better integration with web services.
However the report development is still not good.
We are looking for a much improved report development process and features in version 7, so the question is - upgrade to 2009R2 which looks very solid or wait for version 7 - which may be buggy until the first or second service pack.
Since only a few outsiders have been able to work with NAV 7, this is a big unknown.
From a functional point of view (not development) is this really the equivalent of a service pack or is it a major release with a lot of greatly revised functional features with the potential of a lot of problems in the first release.

kine · 2011-10-06

Each time when somebody ask me if go to NAV 2009 and than on "7" or just wait for "7" I am answering: "NAV 2009 is last version with support for both technologies. If zou do not do the "Big bang" of RTC, it is only way to go through NAV 2009. Even when going in way of "Big bang", it is better to go through 2009 because you can still in some point find out that you need to solve something with classic client. If you will wait for "7", you can miss the time for the transition between classic client and RTC. And what you prepare for NAV 2009 RTC, will be used in "7" without problem, thus no "double investment"."

einsTeIn.NET · 2011-10-06

You have to go through 2009 anyway at least with your development team because of Form and Report Transformation.

rhpnt · 2011-10-06

My humble opinion is that NAV didn't need developers but consultants with strong content knowledge and mediocre programming skills. That's why CAL is so simple with so few functions, methods,... In the future people who today concentrate on content rather than technology will have to move up to a project leading position whilst those who rather spend 10+ hours typing code will stay at this level and move to the .Net environment.

kriki · 2011-10-06

rhpnt wrote:

My humble opinion is that NAV didn't need developers..

You used the correct time : the past.
When I started with NAV (around version 1.2,1.3), was around the time that things started to change.
Now you need consultants with strong content knowledge AND programmers with good content knowledge. There things to program that a consultant with strong content knowledge and poor programming skills could never program and neither a good programmer with little content knowledge.

kine · 2011-10-06

Kriki: :thumbsup:

Belias · 2011-10-06

kriki wrote:

You used the correct time : the past.
When I started with NAV (around version 1.2,1.3), was around the time that things started to change.
Now you need consultants with strong content knowledge AND programmers with good content knowledge. There things to program that a consultant with strong content knowledge and poor programming skills could never program and neither a good programmer with little content knowledge.

moreover...with poor programming skills you probably can "make it work"...
but the big deal is to "make it work fast, well, extensible, understandable, upgradable..."! And sometimes, even an expert developer can't achieve all these things together because there are time/budget/knowledge(?) limits. That said, programming skills are usually underestimated versus "business logic knowledge".
but I think i'm going off topic, so...

I think that my work as a developer consists in: study, apply my knowledge, make my own considerations, do some analysis, document my changes...
STUDY is the first and most important thing, and as you know, mastering C/AL takes about 2 years or even less...in the meantime you learn c/al you also learn a little business logic: posting routines is one of the first thing you learn, for example.
Now the technology is going forward, and we have had to learn some rdlc skills to develop new report and all the other skills kamil said.
I think we just have to do a step back, admit our "ignorance" outside c/al outside C/Side (i'm not talking in general, i'm talking about me) and start learning some other technologies/languages (c# over the others), because they are (and most probably will get more and more) part of the original C/side we studied when we were "noob".
P.S.: ok, we need time to study, and time is always short...maybe we should make our bosses read this thread and ask them if they prefer to give us some time to study @work or find and hire new people...

David_Singleton · 2011-10-06

Learning C/AL should take 2-3 months maximum. It extremely simple, and there is very little to learn.

The important thing to learn is Navision. Understanding the application and how the data model works, so that code you write will work "The Navision Way".

One true skill you need to write Navision code is to know WHERE to write the code.

Belias · 2011-10-06

David Singleton wrote:

Learning C/AL should take 2-3 months maximum. It extremely simple, and there is very little to learn.

The important thing to learn is Navision. Understanding the application and how the data model works, so that code you write will work "The Navision Way".

One true skill you need to write Navision code is to know WHERE to write the code.

I wrote mastering C/AL...I mean, "make it work fast, well, extensible, understandable, upgradable..."
i've seen that sometimes these kind of things are hard to achieve fast because humans are usually following their "habits" and they are afraid to try different approaches...(e.g.: some people still stick on MARKEDONLY instead of temptables)

davmac1 · 2011-10-06

IMO - a good developer needs good functional knowledge and good programming skills.
Fortunately the syntax of NAV is easy to learn. Since there is so much else a developer needs to know, this allows the developer more time to focus on improving functional knowledge and integration with other technologies.
I came from the Cobol world originally, and C/AL is the easiest langauage I have had to learn. The hooks into Excel, Word, and automation are delightfully simple.
Learning to hook into NAV from .net is more difficult because you have all the overhead of the .net langauages to do something simple like connect to a table or a function.
I have always liked the direct connection between a developer and the user. You can determine their business needs, help them use the system better, implement solutions, and develop any code needed to make it happen.
It avoids misunderstandings when the developer can meet directly with the users.

kine · 2011-10-06

I like to talk with customer/end-user in group, where are:

end-user
consultant
developer

It leads to situation, when end-user talks with consultant or developer (depends on if he is more tech or app focuse person) and the second is just correcting the discussion. This I think is best way today. Yes, it means there are 2 persons from partner, but today, when you can meet through livemeetings it is not question of travel cost.

matttrax · 2011-10-07

David Singleton wrote:

Learning C/AL should take 2-3 months maximum

Agreed. I would even argue mastering C/AL should take 2-3 months. You're not dealing with threading, or memory management, or anything more than the loops and variables you learn in the first few weeks of Computer Science 101 (with a few exceptions).

What takes a long time to master is the structure of that code, learning where to put it, and when it has already been written for you. The line I'm drawing may be artificial, but C/AL takes no time to learn, NAV or Navision as a whole, functional and technical, is what takes years. And even then if you think you know it all, you don't. To me a master means three things. In short 1) You know a lot, 2) You know where to find the information you don't know, and 3) You realize that you don't / can't know it all, but never stop trying.

Going back to the original question sort of, I do think that developers who don't learn .NET will be left behind. That's not to say they won't have work, because there will always be legacy customers, but they will get left behind. Or worse, in my opinion, doing nothing but the really boring projects. It just opens up so many more possibilities for the application that I think a lot of the solutions will begin moving to that side. Unfortunately I think that means a lot of the solutions will become more closed. Part of what I love about NAV is that it is semi-open source. I think all of this is still many years off, though.

einsTeIn.NET · 2011-10-07

matttrax wrote:

What takes a long time to master is the structure of that code, learning where to put it, and when it has already been written for you. The line I'm drawing may be artificial, but C/AL takes no time to learn, NAV or Navision as a whole, functional and technical, is what takes years. And even then if you think you know it all, you don't. To me a master means three things. In short 1) You know a lot, 2) You know where to find the information you don't know, and 3) You realize that you don't / can't know it all, but never stop trying.

I'm with you, especially your three point explanation I like. But wouldn't that be also true for .NET itself? I mean of course you don't have to learn business logic and all those database things and so on, but if you take a look just at the .NET Framework it's that much heavy, big, monstrous that it's quite impossible to know everything about it. That would mean you have to search much more for possible solutions. And that could mean that there're much more ways of solution. That again could mean that the quality of those solutions could differ, which means AddOns and solutions for NAV in future will be of very different quality.

matttrax wrote:

Going back to the original question sort of, I do think that developers who don't learn .NET will be left behind. That's not to say they won't have work, because there will always be legacy customers, but they will get left behind. Or worse, in my opinion, doing nothing but the really boring projects. It just opens up so many more possibilities for the application that I think a lot of the solutions will begin moving to that side. Unfortunately I think that means a lot of the solutions will become more closed. Part of what I love about NAV is that it is semi-open source. I think all of this is still many years off, though.

So, you think a team structure with NAV and .NET developers in close collaboration is not a good idea? Or do you mean if an NAV developer is not willing to learn any .NET functionality? I think it will be necessary for an NAV developer to learn at least some basics of .NET, otherwise he will be left behind like you said. But is it really necessary to learn .NET in a whole (if that's possible at all) or would it be enough if there is some clever collaboration?

matttrax · 2011-10-07

einsTeIn.NET wrote:

which means AddOns and solutions for NAV in future will be of very different quality.

The quality now is very different, I don't think that changes anything. I've seen ridiculously poor code written for add-ons, and I've seen brilliant code for add-ons. There is always another way to write code for something, too. The .NET framework is huge, and I do think the same thing I said for NAV applies. You'll never know it all.

einsTeIn.NET wrote:

So, you think a team structure with NAV and .NET developers in close collaboration is not a good idea?

Depends on the project and the budget. The customer may not want to pay two developers to work at the same time collaborating on a solution when one "should" be able to do it. Collaboration is a part of any team, whether it be developers, consultants, or whatever. Everyone will have different skill sets and know things that others don't. So it's always good to have people to bounce ideas off of. Waldo had a good presentation a while back about "What every NAV developer should know." You don't have to know exactly how to do it, but you do need to know things are possible and how to figure out how to do them.

I've posted a few times that I think the future of NAV is in .NET. C/AL will be around for a long time, especially in legacy customers, but just look at Microsoft actions so far. Rewrite the entire application in .NET with the RTC. Translate the C/AL code into .NET when it's compiled. Introduce .NET variable types, add-ins, web services, etc. Future: get rid of classic client / non-.net interface. Get rid of classic reporting and move to SQL, which you can use .NET in.

I personally think anyone who doesn't see it coming is crazy. Again, I think it's going to be a while, but come on.

kine · 2011-10-07

Knowing .NET was big plus before and it will be in future. If you had some problem in classic client, someone with .net knowledge on some level could create Automation to solve the problem. Now it will be much easier to use external assemblies and create them, so you do not need so deep knowledge like when creating the automations. Of course, if you want to solve komplex things through .NET, it will be good to have someone with deep knowledge, but for beginning, it is enough to know how to create assembly with few classes doing some basic things.

einsTeIn.NET · 2011-10-09

matttrax wrote:

The quality now is very different, I don't think that changes anything.

Yeah, that's true. But there's one big difference between the NAV world and the .NET world. For a certification of your AddOn you need some kind of review by Microsoft. I know there are also some problems in the way the certification is awarded, but that's another topic. But I've never heard of something like that for .NET. Is there any?

matttrax wrote:

You don't have to know exactly how to do it, but you do need to know things are possible and how to figure out how to do them.

matttrax wrote:

The .NET framework is huge, and I do think the same thing I said for NAV applies. You'll never know it all.

Exactly that's the point. But that would mean it's almost impossible to become an all-around specialist. And that would mean there's no way around an NAV developer team with at least one NAV developer and one .NET developer. So, solutions will be more expensive in future and collaboration must grow.

Do you think we need some kind of Style Guide like the one that existed for NAV some time ago? That would at least help to identify in a first step all the quick and dirty kludge solutions.

kine · 2011-10-09

So, solutions will be more expensive in future and collaboration must grow.

Definitely, and with the pressure from Microsoft to sell NAV to small-market (or lower mid-market) and AX to mid-market, it becomes more crucial to push the cost down. It leads to develop addins which are re-sellable and not the customization for only one customer.

matttrax · 2011-10-10

kine wrote:

It leads to develop addins which are re-sellable and not the customization for only one customer.

I think that will be true in some cases, but not all. Maybe it's just the types of customers that I deal with, but the vast majority of them don't need these combination C/AL and .NET solutions for 99%+ of their issues. You'll see the occasional web front, or the occasional integration with another piece of software. A lot of it depends on how much the customer wants to invest in a solution that works now, and how much they want to invest in a solution for the future.

I also think it's interesting to look at the contradictions between how NAV services, or any service industry really, work generally and the profitability goals of most businesses. That being make the most money for the least amount of effort / investment (i.e. add-ons). Whereas NAV prides itself on being customizable specifically for the customer, which is a direct return on work performed. Of course people only want to do work once, then sell it over and over again.

At the end of the day, the details are changing, the big picture isn't. We provide solutions for customers, based on the available technology, what we know about their business, and the budget they have available. Whether that's C/AL code, .NET, add-ins, add-ons, project management services, whatever, I don't see that changing. If you're a customer, you generally don't care what the solution is written in (assuming development), you just want it done correctly for the least amount of investment. All of the work in between conception and delivery isn't changing that much. In my opinion anyway.

The future of NAV developers

Comments

Categories