The future of NAV developers

kine

Of course, this "high-level" view doesn't change, and yes, .NET is not needed in NAV to be able to develop what customer wants. But partner with knowledge of .NET could have "bonuses" for the customer when customer is choosing partner (like nice eyes catching addins, web portals etc.). And this is what sells the product, not the basic functionality and customizations. It is the way, in which partner could be "different" than rest of partners.

David_Singleton

matttrax wrote:

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

=D> =D> =D> =D> =D> =D> =D> =D>

I couldn't agree more with that statement.

David_Singleton

kine wrote:

... .NET could have "bonuses" for the customer when customer is choosing partner (like nice eyes catching addins, web portals etc.)...

The word you are looking for is "fluff"

Sadly though you are right, too many customers chose the eye candy instead of what is best for their business.

matttrax

kine wrote:

But partner with knowledge of .NET could have "bonuses" for the customer when customer is choosing partner (like nice eyes catching addins, web portals etc.). And this is what sells the product, not the basic functionality and customizations.

Sure, but I'll keep driving home the point. How is this different than today? Bonuses may sell the product, but they don't keep customers. How many companies are certified for add-ons they haven't sold or used in years? Or know the buzzwords that customers want to hear? I mean, it's like saying your company has combined 100 years experience implementing NAV when two people have 15 years each and the other 30 have 2 years each. A company will market itself the best way it can that will allow it to make the most money.

I would say now it's more eye candy instead of ear candy. NAV was pretty simple before in terms of look and feel. There wasn't much to brag about. Partners relied on their experience, certifications, and add-ons to distinguish themselves. Now every partner will be demoing the RTC, no difference there. They can pull out the demo add-ins from Microsoft, same as everyone else.

Maybe it's because I have only been doing this for six years, because I do 90% development, or because I'm still pretty fresh out of college (same time, six years). I know most of the senior people here are well over ten with NAV and have experience in other industries as well. I just don't see all of this as that big of a deal. Going back to the title, where I do see the future of NAV developers? With opportunities to do more, learn more, and work with new and exciting technologies. I'm excited for all of the things that have happened and are coming down the pipe, but I see a lot of people stuck in their ways of "It ain't broke so don't fix it."

einsTeIn.NET

matttrax wrote:

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.

Yeah, that's maybe true. But the question is if they don't need it because it was just not available. I mean, I don't know what future solutions could look like. Maybe while possibilities will grow, desire for something completely different, integrative or more user-friendly will also grow. And you also have to keep in mind that most of the customers don't even know what their problem is. So, most of them will follow your advise which for sure is related to the NAV world and considers all its limitations.

einsTeIn.NET

David Singleton wrote:

matttrax wrote:

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

=D> =D> =D> =D> =D> =D> =D> =D>

I couldn't agree more with that statement.

If you agree to that statement then I see some slight contradiction to that statement:

David Singleton wrote:

..., too many customers chose the eye candy instead of what is best for their business.

I mean both of them are true from a certain point of view. But I think the problem is, many customers are blinded by some nice visual features and don't care about the real issues why they are searching for another solution in that point in time. Once they decide for one solution (which means in NAV world they decide for one partner) they are or become angry about the costs. Not so much about the cost of the solution itself, that's even in some cases a fixed price, but about all the small things and consultancy around the solution. They simply don't understand in which case they're going off-topic of the solution. I'm sure that's also up to bad explanation and unclear statements of the solution provider, but that's another topic.

In the future that will change. You'll be able to buy 30 small, visual impressive eye-catcher solutions from 30 different "solution" providers. I mean for a real solution provider, it'll be like Matt said, all of the work in between conception and delivery won't change that much. But maybe there'll be also many providers of those small eye-catcher solution that just

matttrax wrote:

want to do work once, then sell it over and over again.

In my opinion a company shouldn't decide for NAV because of its customizations, its visual look-and-feel or its out-of-the-box possibilities. For sure you have to consider those aspects in your decision as well. But the main reason should be the quality of the consultancy around the solution. If someone don't know about business processes then he can't help you in optimizing them. And that is in my opinion the main reason to search for another solution. Otherwise you could stay at your old one.

All of you know about the problems of the last few years in finding proper solution providers with good consultants. And I really can't think of what will happen if solution providers of the .NET world realize how to make money in the NAV world. It'll become even more complicated to find a proper partner.

David_Singleton

einsTeIn.NET wrote:

If you agree to that statement then I see some slight contradiction to that statement:

a/ you misquoted me, b/ there is no contradiction. 8)

einsTeIn.NET

matttrax wrote:

Going back to the title, where I do see the future of NAV developers? With opportunities to do more, learn more, and work with new and exciting technologies. I'm excited for all of the things that have happened and are coming down the pipe, but I see a lot of people stuck in their ways of "It ain't broke so don't fix it."

I don't think all the uncertainty is related to no one wants to change the good old stuff. I'm totally with you, I'm excited and the developer in me is looking foreward to all the opportunities. But in terms of making decisions for a company I have some doubts about the future. But I'm glad I'm at least able to discuss it with all those educated people around here.

einsTeIn.NET

David Singleton wrote:

a/ you misquoted me, b/ there is no contradiction. 8)

:? I'm not sure, maybe I missunderstood you. Could you please explain?

matttrax

einsTeIn.NET wrote:

In my opinion a company shouldn't decide for NAV because of its customizations, its visual look-and-feel or its out-of-the-box possibilities. For sure you have to consider those aspects in your decision as well. But the main reason should be the quality of the consultancy around the solution.

That's why you choose a partner, not why you choose a solution. If the SAP partner was better at implementing, but SAP cost $1 million and NAV costs $100,000 (not an understatement), you'd have to determine if it was 10x better or not. They should make their decision based on all appropriate factors. There are around 200 NAV partners in the US last I checked. Just because you talk to a bad one during the sales cycle doesn't mean you can't like the product but go with another solution center.

einsTeIn.NET

Of course, your given budget is another knock-out criterion.

matttrax wrote:

Just because you talk to a bad one during the sales cycle doesn't mean you can't like the product but go with another solution center.

I'm not talking about a product, I'm talking about a solution. That's a difference. And for sure your decision for a partner should be based on the same reasons. Software/Tools/Products are exchangeable. Sometimes it's not easy, but they are. That's what I said, if you have an appropriate partner moving to NAV 7 and all its possibilities won't be a problem. If you do not have or you are searching for AddOn solution that your partner could not provide then you have to look for another appropriate partner (for that part). And that will become more and more difficult in future, I'm afraid.
Maybe my post is a little bit mistakable. I guess it's more clear if I had said:

einsTeIn.NET wrote:

In my opinion a company shouldn't decide for NAV for a solution because of its customizations, its visual look-and-feel or its out-of-the-box possibilities. For sure you have to consider those aspects in your decision as well. But the main reason should be the quality of the consultancy around the solution.

David_Singleton

The problem is Einstein that you started a thread about the future of NAV developers, but that is not the question you are asking, and not the topic you are discussing. You are discussing development teams.

Big difference.

einsTeIn.NET

Yeah, I know we moved a little bit to another topic.

David_Singleton

einsTeIn.NET wrote:

Yeah, I know we moved a little bit to another topic.

There is nothing wrong with the subject moving through a thread. But I was referring to your original post.

einsTeIn.NET wrote:

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?

I see the question you ask as a general one of how partners need to evolve and how they need to address the new requirements.

But in terms of "The future of NAV developers" (the topic), I can't see that the future has ever looked as good.

I don't see that NAV developers need to move in the .NET direction, I see that NAV developers need to head more into the business analysis direction. One good business analyst will feed 3-5 developers, whether they be .NET or T-SQL or C/AL programmers. So the smart person that has 5 years NAV programming, now has a huge opportunity to leverage those skills and move up the chain.

einsTeIn.NET

I think I see what you mean. I choosed that subject because of the question that was asked at Christians session. For sure I did some interpretation on that question and maybe the original questioner didn't mean all of that.
It was just the starting point of a great discussion.

David Singleton wrote:

I don't see that NAV developers need to move in the .NET direction, I see that NAV developers need to head more into the business analysis direction. One good business analyst will feed 3-5 developers, whether they be .NET or T-SQL or C/AL programmers. So the smart person that has 5 years NAV programming, now has a huge opportunity to leverage those skills and move up the chain.

Of course there'll be great opportunities for NAV developers. But keep in mind that not all NAV developers are able to do good business analysis and some of them just don't want to do something like that. I know there're many possible ways. I think Kamil painted that picture of team collaboration of developers with different skills participating from each other. That could also be very interesting.

I don't see a clear picture of what will be needed in future for a certain company. So, the general question would be, how could you decide from a company's point of view how to go on with your current team. I mean the same question could be also interesting for an individual. First of all you have to decide what you want to do in future and afterwards choose the way of change. But you won't know if your company will need someone like you when you travelled that way. Of course you could talk to your boss and ask him about his plans, but maybe you won't get the right answer. Not because your boss is lying or don't want to tell you some internals, but just because he don't know it better. That would mean you have to consider that you maybe have to change your company when you decide for a certain way.

matttrax

David Singleton wrote:

I don't see that NAV developers need to move in the .NET direction, I see that NAV developers need to head more into the business analysis direction...So the smart person that has 5 years NAV programming, now has a huge opportunity to leverage those skills and move up the chain.

Just curious, do you see the business analyst as more important than the developer? I see them as equals personally. Without proper analysis you can't do the right work and without proper development you can't do the work right.

einsTeIn.NET wrote:

So, the general question would be, how could you decide from a company's point of view how to go on with your current team. I mean the same question could be also interesting for an individual. First of all you have to decide what you want to do in future and afterwards choose the way of change.

I asked myself the same question a few years ago. Do I want to stay with NAV? If I do what do I want to do with it? For me, I have absolutely zero interest in doing anything other than development full-time. Part of the territory is that you get to do other types of work, analysis / project management / etc, in this line of development, which is nice. I decided that for me, and for the next few years, the best thing I could do was to continue learning about NAV, but learn .NET as well. The RTC was not necessarily a deciding factor, but it helped. I could semi-return to what I really enjoy doing, which is more user-centric. I studied things like Human Computer Interaction, Information Visualization, Educational Technology, etc. Those things applied in Classic, but they were very limited.

This might sound a little weird, but I think a great NAV developer needs to be an expert at NAV, not NAV programming. That in turn may lead you down some of the more functional roles, but it doesn't have to. You can just as easily go towards .NET, or even SQL Administration / Programming / Reporting. Those two are just the technologies that will apply to every installation. You could learn more about web portals, business intelligence solutions, SharePoint / Performance Point. I guess the point is, these are things you should either decide on your own that you want to do, or be talking with your manager about doing. Knowledge is knowledge and it can only strengthen your position.