Can we please stop giving useless answers?

Miklos_Hollender

Like "ask your NAV partner" or "you need to customize". More often than not, the person asking the question is from a beginner NAV partner trying to learn how to customize! So give them the code (at least a rough outline: loop through this, that etc. no need to dictate every command, some things people must learn on their own) or don't answer.

Maybe some of you had the luck to start your career at an established NAV partner where more senior people could train and help you. Many of us didn't.

More often than not it works like this:

A company which is either doing some other ERP like SAP, or doing some other Microsoft product like Exchange consulting, is thinking about expanding their product portfolio. So they have a good customer, and the customer is thinking about implementing NAV. And then the owner goes OK let's do it, you there and you there are our NAV department now. You, who could program Exchange in Visual Basic are our programmer, you who went to business school and/or worked with SAP B1 in your previous job are our consultant. Yes, you will have your trainings. Finance training is in April, and programming training March. But the project starts in February. They register at Microsoft, get a dev licence, read the training manuals and give it a go.

My first job in 2002 was SunSystems ERP consulting and taking up NAV, we were surpised that we are even allowed to program it The second one in 2004 was a technical company, Microsoft Exchange consulting etc. taking up NAV.

Mibuso was a lot of help back then when I needed it. But I remember how I, as a partner, and programmer, hated the "ask your partner" and "you must customize it" (without telling how) answers.

So let's not do it now, OK?

jglathe

:thumbsup:

ppavuk

I do agree with you, but beginners should at least read a programming guide, before they starting to ask a stupid questions.

DenSter

I don't agree with that at all.

Many times the question is a very general question of how to do something, by someone who clearly has no clue about how NAV works. If what they are asking is not part of standard NAV, the answer is "that would be a customization, here's what the standard product does". I just don't agree that we would be obliged to provide a design and pseudo code to actually make that customization happen, and many times that's not what the question is for anyway.

The answer 'ask your partner' is just as much a legitimate answer as a bucket full of pseudo code. In fact, I always hate it when someone provides pseudocode, because 9 times out of 10 there are serious flaws in it, and the design is often ill thought through as well, and I can't tell you how many times I bite my tongue when I see another dumbass piece of advice with lots of crap code in it. I don't see anything wrong with saying "ask your partner for x". I do agree that it often helps to specify what exactly to ask, and I do agree that we should provide some additional context of what to ask for, but it is definitely legitimate advice for us to tell people to go to their partners.

In my opinion, a LOT of the so called code and design approaches that are provided in these forums are completely false, and I would never advise my customers to take it (in other words: there is a LOT of crap advice on these forums). In fact most of the time, the more code in the post the more wrong the post is. Most of the time, you are much better served having a real conversation with your partner than to follow some bogus advice that sounds good but is no help at all.

kine

Another thing is, that the partner is responsible for the system, and if the customer e.g. based on some "advice" from the forum modify it and the code is not correct (because it is "created" on limited information without contex and knowledge of the system) it is something which make only damage.

Each answer must be carefully written to take into account things which were not described. Rather than "do not give useless answers" I will appeal to "do not write expert answers without knowing enough about the context". It is much more dangerous :!:

davmac1

In a perfect world, we would all be born 30 years old with 8 years of NAV experience! 8)
I got my start at a NAV end user where I had gone to work on their other systems, when the in house NAV guy walked out.
I was charged with supporting the current system and developing a new one.
Fortunately I had a lot of non-NAV ERP experience, so I was not completely lost.
My personal course of action:
Download every NAV manual available and read all of them
Certify
google
Find Mibuso - my personal lifesaver! :thumbsup:

DenSter

kine wrote:

"do not write expert answers without knowing enough about the context". It is much more dangerous :!:

:thumbsup:

Alex_Chow

Miklos Hollender wrote:

Like "ask your NAV partner" or "you need to customize". More often than not, the person asking the question is from a beginner NAV partner trying to learn how to customize! So give them the code (at least a rough outline: loop through this, that etc. no need to dictate every command, some things people must learn on their own) or don't answer.

Maybe some of you had the luck to start your career at an established NAV partner where more senior people could train and help you. Many of us didn't.

More often than not it works like this:

A company which is either doing some other ERP like SAP, or doing some other Microsoft product like Exchange consulting, is thinking about expanding their product portfolio. So they have a good customer, and the customer is thinking about implementing NAV. And then the owner goes OK let's do it, you there and you there are our NAV department now. You, who could program Exchange in Visual Basic are our programmer, you who went to business school and/or worked with SAP B1 in your previous job are our consultant. Yes, you will have your trainings. Finance training is in April, and programming training March. But the project starts in February. They register at Microsoft, get a dev licence, read the training manuals and give it a go.

My first job in 2002 was SunSystems ERP consulting and taking up NAV, we were surpised that we are even allowed to program it The second one in 2004 was a technical company, Microsoft Exchange consulting etc. taking up NAV.

Mibuso was a lot of help back then when I needed it. But I remember how I, as a partner, and programmer, hated the "ask your partner" and "you must customize it" (without telling how) answers.

So let's not do it now, OK?

:thumbsdown:

There's is so much wrong in this post I don't even know where to begin.

For complex problems that requires the onsite or partner's help, I'm going to respond by saying "get with your partner".

Go ahead and try to get to the bottom of questions like "why doesn't my customized inventory valuation report balance with my customized inventory posting setup"

Miklos_Hollender

DenSter, Kine, Alex - the whole point is that it is NOT customers, but beginner partners asking questions here! Why would a customer come here? They typically have partners. Or easily find another one. Plenty of competition... But partners have nowhere to go, so they come here...

Somehow you all missed this part...

Do you somehow assume that partners are all experienced professionals? We all know this is an industry where most of what needs to learn is not in the trainings, not in the manuals, only experience helps... so those partners who don't have one employee at least who is doing this for at least 2-4 years, come here to ask questions. Customers I think don't or very rarely.

kine

I understand what you want to tell. But from other point:

If somebody is starting the job from "green field", answer to the complex question cannot be answered through the forum and be enough detailed to not make wrong impact. I know about what you talk. We are starting AX group in our company without any experience. But we found another AX partner, which was able to give us good classes to quickly kick the people into the product. My collegues after that were able to find enough info on forums etc. but they already had some basic knowledge to understand the answers. It means, I cannot start the job without collecting some basic know-how, and I think the forum is not good to start. The knowledge transfer is too limited. And If I am learning something new, I must expect that I need many self-learning from manuals and books.

matttrax

Miklos Hollender wrote:

So give them the code

Could not disagree more. I'm not saying that learning by example is a bad way to learn, I do it all the time. A beginner should be learning concepts and fundamentals, though.

When I started I didn't know where to get manuals, but that's not the case anymore. The Application Designer's Guide is built right into the client Help menu. There is training material on MSDN. It's much easier to find than it used to be. There's no excuse not to have read it first.

It's part of the reason I really don't post anymore. Everyone wants a shortcut. I don't recall ever asking someone to "give me the code", if so I should be scolded. How about saying "Point me in the right direction", "Where should I begin?", or "I've tried this and it isn't working".

Mibuso and DynamicsUser were influential in me becoming what I am, but it wasn't because they did my job for me. The forums are just not a place for teaching anymore.

Alex_Chow

Miklos Hollender wrote:

Do you somehow assume that partners are all experienced professionals? We all know this is an industry where most of what needs to learn is not in the trainings, not in the manuals, only experience helps... so those partners who don't have one employee at least who is doing this for at least 2-4 years, come here to ask questions. Customers I think don't or very rarely.

:thumbsdown:

If the partner that's helping a $50 million a year company go live with NAV and still asking fundamentally wrong questions, then by default, you're contributing to an eventual failed implementation. It's a natural progression for that company to hate NAV and speak poorly about it when they switch to Oracle or something. To that person asking for help, he/she will view mibuso as a waste of time.

You're not helping people by answer questions that you do not know the context of. This is why "get with your partner" is a legitimate response. If they don't have someone knowledgable in NAV or have access to someone knowledgable, they probably shouldn't be implementing that $50 million a year business.

DenSter

I again agree 100% with Alex on this one

davmac1

While I agree with Alex and Daniel, the ugly reality is that many times, the customer has been sold either by a very good salesman or close friend or family member, and the person responsibly for the success of the implementation is looking for answers.
This could be a partner problem or a end-user problem.
Why end-user - sometimes they do not want to pay for good help.
One question a partner should always seek answers for is why a customer wants to switch partners. There may be good reasons why the customer should be unhappy or maybe their existing partner will throw a party when they leave.
Why partner - maybe they don't have the skills or in the case of a large partner, the people assigned to the customer lack the skills.

Alex_Chow

davmac1 wrote:

While I agree with Alex and Daniel, the ugly reality is that many times, the customer has been sold either by a very good salesman or close friend or family member, and the person responsibly for the success of the implementation is looking for answers.
This could be a partner problem or a end-user problem.
Why end-user - sometimes they do not want to pay for good help.
One question a partner should always seek answers for is why a customer wants to switch partners. There may be good reasons why the customer should be unhappy or maybe their existing partner will throw a party when they leave.
Why partner - maybe they don't have the skills or in the case of a large partner, the people assigned to the customer lack the skills.

Yes, it's ugly and a very sad reality in the ERP industry.

Nonetheless, by trying to "help" the person when you don't know the context, you're contributing to the downfall rather than helping it.

The answer of "ask your partner" is a good indication for the programmer asking the question to know that he/she is over his/her head and REAL professional help is required rather than bullsh*ting your way through.

Even if they're a partner, they will realize that they're not qualified and maybe hire a contractor that really knows what's going on. Assuming they know what's good for them...

David_Cox

This has gone way off topic, which is about "useless answers" and not $50m implementations!

Some users might work for small resellers, some might struggle with the terminology, others might have good code skills but not familiar with an accounting practice or workflow, most would have asked "in house" if they have the support network before asking here.

The topic is more about the quality of the answers, after 17 years from "Navision NAV 1.3 and N.O.L.U.G (email support group)" to "Dynamics NAV and Mibuso" if I am stuck with a bit of code I will Google and read the threads here, Microsoft Partner Source, Support Articles and in the DynamicsUser forum.

After a while you can identify the good answers from the poor answers, some older threads might not be applicable to the version you are working with, functions, processes and sample code can also be deprecated.

However reading the topics and replies will often "point you in the right direction", even a poor answer looked at against a good answer might have some part that has a use to someone else's issue.

Recently I was working on some code and found the answer by using code segments from two or three different topic code samples.

Just my 2 cents, "One persons "perceived" trash can be another's treasure".

David

Miklos_Hollender

Alex:

>If the partner that's helping a $50 million a year company go live with NAV and still asking fundamentally wrong questions, then by default, you're contributing to an eventual failed implementation.

More like $5M (SMB product, remember, $50M a year can afford AX or SAP) and I have never seen a failed implementation, how is it even possible? They want to get paid so they will tough it out, hack it until it works, and eventually learn. Of course working 400 days on the first project but getting paid only for 60 hurts but this is the price of learning. Best way to learn is by imitation, this is why I am in favor of detailed answers. Like learning a language, it is not as much as putting individual words together, more like replacing words in "often used sentence templates" we picked up during conversations. I am a big fan of the pattern recognition ability of the human brain, I think the usual inductive/deductive reasoning is overrated.

> If they don't have someone knowledgable in NAV or have access to someone knowledgable, they probably shouldn't be implementing that $50 million a year business.

Ideally not, but nobody will give up on a project already started so without this kind of help it only ends up being worse...

I would agree more with bringing in someone more experienced, but is this even realistic? There are two cases why the customer chose them. Either they were not entirely honest with their experience, not outright lying, you know just the usual "technically true" sales bovine feces Like when salespeople say "the company has 100 years of combined experience in 3 ERP software" and it is technically true, but none of them is NAV In this case bringing in help would be a huge loss of face. T

he other, more honest, hopefully more common casesis like "Look customer, we are beginners, an experienced company would quote you 100 days at €800 a day, we will do it for 50 days pay for you no matter how much it takes. Deal?" In this case it is very, very hard to justify external costs like bringin in someone else to the business owners given that they are losing money already.

Alex_Chow

:roll:

I see where you're coming from. You're used to working in smaller implementations $5m as oppose to the people in the US where the companies that run NAV are much larger. It really doesn't matter, if you're fine with poor implementation advice assuming that people will "tough it out", you'll be in a lot of trouble when that $5m business grows into a $50m business. Trust me when I say that I've learned this the hard way.

And no, a $50m business will not be using AX or SAP. Again, reading your posts, you're making a lot of assumptions that you should NOT be making.

Alex_Chow

David Cox wrote:

However reading the topics and replies will often "point you in the right direction", even a poor answer looked at against a good answer might have some part that has a use to someone else's issue.

You don't think the advice of "get with your partner to figure out why your customized inventory valuation is different than your G/L" is a good reply?

For straightforward programming questions, yes, I think the board does a very good job of point people in the right direction. But it should not be the sole source of all answers of your NAV questions.

Marije_Brummel

Personally I think it is best to ignore questions and answers you don't like or agree with.

This is what I do.

Truth is that the forum has changed. Or at least that's my opinion.

I had much more "fun" here five years ago than I have now.

It is not mandatory to answer questions, not even for MVP's.

I think this viewtopic.php?f=23&t=56679 is an example of a post that I would just leave alone.

If someone else wants to step in and does start, then let them be.

When something happens that is inappropriate the moderators should step in.

If you don't agree with this I guess you should start your own forum or blog.

ppavuk

Just have a look to this topic. It is a beautiful example. Is this answer to most of questions discussed in current thread, isn't it?

viewtopic.php?f=23&t=56666

Marije_Brummel

It would also be a thread that I would ignore.

If someone wants to pick it up than its ok.

I agree with Miklos that answering "RTFM" does not add any value. Leaving the thread unanswerd would be better. But thats just my opinion.

ppavuk

The issue isn't in answers, the issue is in questions. In last years a hordes of yellow-beaked developers joined NAV world, and they even didn't bothered to read basic stuff.

Half of topics on old good Mibuso are just flooded by people who haven't got how setrange works...

In our times, people at least read something before asking. Twitter generation :x

David_Cox

Alex Chow wrote:

David Cox wrote:

However reading the topics and replies will often "point you in the right direction", even a poor answer looked at against a good answer might have some part that has a use to someone else's issue.

You don't think the advice of "get with your partner to figure out why your customized inventory valuation is different than your G/L" is a good reply?

For straightforward programming questions, yes, I think the board does a very good job of point people in the right direction. But it should not be the sole source of all answers of your NAV questions.

David Cox wrote:

Some users might work for small resellers, some might struggle with the terminology, others might have good code skills but not familiar with an accounting practice or workflow, most would have asked "in house" if they have the support network before asking here.

Hi Alex, you are correct I was coming from a Consultant/Developer perspective, as you can see in my post I did say to exhaust all "in house" options first, this would include both resellers and end users, the forum should not be a substitute for training for a developer or end user but part of a support network.

Your example would be a good end user answer, where the end user is trying to avoid paying for consultancy or training, we could ask if they have already consulted with the partner, and what advice they have already taken.

Regards

David

matttrax

ppavuk wrote:

The issue isn't in answers, the issue is in questions.

I agree. It's not that there weren't bad questions before, but you could prod / poke the requester into giving more information; into telling you what they had already tried, what their thought process was. You could make it into a learning experience for everyone. I honestly feel like 98% of the time you can't do that anymore. The people asking questions don't want to learn, they want someone to do their homework for them. As Mark said, it's just not fun anymore. It was exciting to see the light bulb go off when you guided a person to the answer. I don't feel like I teach a customer or partner when I give them the code line for line, I just help them get the job done.

If I wanted to do NAV work for free I would find a nice non-profit or company that I truly cared about and donate my time. I personally got into the forums to learn and to teach, and I don't feel like I've been able to do much of either lately.

ppavuk

matttrax wrote:

ppavuk wrote:

The issue isn't in answers, the issue is in questions.

The people asking questions don't want to learn, they want someone to do their homework for them.

:thumbsup:
Exactly what I meant! I always happy to help to someone who trying to sort out things and doing his best, but if someone just not bothered to read basic docs - where the point ?

Alex_Chow

Mark Brummel wrote:

It is not mandatory to answer questions, not even for MVP's.

I agree.

However, in the case that Miklos Hollender is pressing the forum to give answers, even if the context isn't known. For example, here's a recent reply where I used the "get with your partner" answer: viewtopic.php?f=23&t=56617

The standard functions clearly did not work and it was clear to me that some developer had messed with the warehouse entry. Do you want to just leave the guy hanging and let him assume that it was a Dynamics NAV bug? Assuming the financial impact of this supposed "bug", he is more likely to talk bad about NAV and how it's the worst piece of crap ever, instead of directing his energy on resolving the solution with their partner (even if he doesn't like to pay).

Marije_Brummel

Alex, mate, trust me; you always do a great job, whatever your answer is. 8)

And in this specific case you are 100% correct. :thumbsup:

davmac1

My my Alex, looked like you got a little frustrated in your answer on your last link.
Now you are making me a feel a little guilty about referring one of my customers who wants free help to Mibuso.
I still think this forum is great, and with the help of google, we can find past answers - which I do regularly.
In addition to consult your partner, maybe we should point people to our NAV books as well - we need to encourage our authors and pump up their sales - it is good for all of us. :thumbsup:

DenSter

I just reject the notion that "talk to your partner" is a useless answer.

Often I come to that conclusion after much deliberation, when there are too many questions, too many variables, and you'd have to make too many assumptions to provide meaningful answers. In those cases, actual people have to come together to work on the problem, and a forum is simply not the right place, so then the answer is "talk to your partner". If the OP works for a partner themselves, all they'd have to do is say "but I AM the partner and I am stuck" and we can help them get the assistance that they need.

What I have a problem with is when people instead get angry and start demanding answers, or other forum mates saying that the answer I thought long and hard about is useless.

David_Singleton

Quite a lot of topics in this thread. I am sure that (like me) everyone has opinions on all of them, but as a start lets look at the opening topic.

<MHO>

Can we please stop giving useless answers?

I think this is a good point, and open to each person's interpretation, but the message says something quite different to the Subject.

Some of you have noticed that over the years I sometime "drop off" the forums for a longer periods of time. This happens because I lose the cost/reward balance and stopping is the only solution. To me there are a number of costs of forums, the primary one being time, but the secondary ones being stress, and lost business. By lost business, I refer to the posts that go over the line of teaching and into consulting and thus in general we have customers that start to expect things for free. The rewards are primarily the joy of helping someone to achieve a goal, it's something I have always enjoyed, and if there was money in teaching, I would be a full time teacher. Of course along with teaching comes learning, and of course over the years I have picked up actual business from customers reading my posts, so there are also side benefits.

In other words, I have to enjoy it or I don't do it. But we seem to often now go through these phases of stupid questions, followed by stupid answers. The problem is that stupid answers encourage more stupid questions and a vicious circle starts. Simply answering "did you try search" or "you need code" is a stupid answer, an answer like "you have not given enough information" or "you need to contact your partner" is a smart answer (IMO). And to address a specific topic, if a partner is asking a question that a partner should know, then they need to prefix this information, otherwise we should assume it is an end user question.

So when things go crazy I simply stop answering all questions, I simply don't log in for a month. Why? Well the problem is that if I log in and see a stupid answer, I feel a desire to help the original questioner and give them "better" advise, and that is most often taken as an insult by the stupid answerer. And why do I want to get involved in this if there is nothing in it for me anyway.

I am not going to say what forums are supposed to be for everyone, but I can say that FOR ME this is not what they should be. For me questions should not be answered unless there is enough detail to answer them correctly. If there is not enough information I used to ask for more. But this current generation is just too lazy that I think "why bother", and I simply close the browser and move on.

If we stop answering the stupid questions, they will simply go away or at least reduce in volume.
</MHO>