mibuso.com

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

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.

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.

Kriki:

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...

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)

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.

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.

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.

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.

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?

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.


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.

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.

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?



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.

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.