Something I have noticed about the Navision development community (in the UK at least) is the seemingly total lack of real programmers. In my experience, 90% of Navision developers are not professional programmers who have added Navision Development to their other languages. Most seem to be ex accountants, or managers, or people from totally non IT backgrounds. In my opinion this is the major reason why most third party Navision modifications and bespoke that I have encountered is badly written, badly structured and badly documented. Speaking as a developer who trained in in C++ and VFP (amongst others) before encountering Navision, I am appalled at the basic lack of formal knowledge in the Navision world. It concerns me that development on major sites is being undertaken by people who are Acccountants or trainers or implementors one day; and software developers the next. In my experience, there is a wilfull ignorance of such things as coding standards, documentation, understanding of data structures, source control, testing procedures etc; all of which are bread and butter to professional software engineers. Don’t get me wrong. I’m not saying that if you are a product specialist that you cannot become a competent programmer. Of course you can, but you have to learn structured development skills first. To not do so is to produce amateur code. It concerns me that the weakest link in the Navision world is this amateur approach to software development, which I believe will restrict the growth of Navision within the UK. I believe that one of the reasons that this state of affairs has come about is because the Navision world has not encouraged professional developers from other languages and disciplines to become Navision developers. I noticed this on my base and advanced developer courses at Navision. On both courses, I was the only formal programmer in the room, and certainly the only individual who commented and documented each stage of development. Are NSC’s closing rank to prevent established IT professionals from entering the market? What does the group think? Has anyone else noticed this state of affairs, or have I been staggeringly randomly accurate in my experiences of shoddy Navision development and developers? R. << Sound of Royster franticly donning flameproof suit and diving for cover >>
Come on out Roy. Really it’s OK. I for one, am a professional programmer. Started with dBase III+ and Clipper way back in the late 80s, through Oracle, SAS, a couple of others, and eventually, to Navision. I agree with you that there could be more documentation in the code. I’ve only had experience with two add on products, but both code have been better documented. That said, before Navision, I had never used an accounting package before in my life. And I think that in the Navision world, a programmer doing modifications with no accounting experience is a far more dangerous animal than an accountant doing modifications with no programming experience. And as for the other NSCs that I’ve dealt with, most of the programmers seem to have had some programming education/experience.
Welcome to book-keepers & lamers crowd !!!
Degree in Computer Science… Languages studied/learned/played with/developed with over many years: C/CPP/Java/Assembler(x86,MIPS,Z80)/Pascal/Perl/PHP/HTML/ASP/VB/BASIC/FORTRAN and of course Navision C/AL… Just another language in the end, with its own syntax and rules… I dont know how my message ended up before Matts…it was posted afterwards. I disagree with Matts comments regarding accounting people programming vs programmers programming accounting s/w. Sure they must understand basic accounting… but the rubbish code I have seen by some accounting people or people with no programming training is appalling! Craig Bradney Technical Manager Navision Solutions & Services, Deloitte Touche Tohmatsu Edited by - cbradney on 2001 Jul 06 00:01:24
In reply to Craig’s comments. This is exactly my point. The prevailing attitude amongst the UK Navision community appears to be that it is fine, indeed preferable to have accounting people programming rather than programmers learning accounting. This is a crazy attitude, do programmers not have to learn product specifics for any other market? Of course they do. R.
I just love this topic. I’ve had this debate before when talking about who to hire as Navision developers. I’ve always looked at the two diffent terms: And I think we need both. Whereas the Navision Programmer is the “REAL Programmer”. He thinks in “code” etc. Often when the users starts to tell about their problems/needs then in his head (and sometimes even online) create the solution. He likes to “just do it”. His background before Navision is as a programmer of other PC languages (Visual Basic, Pascal/Delphi etc.). The Navision Developer thinks more in whole solutions. He listens more to the user before comming up with a solution. Often he turns around the users needs and he doesn’t always do what the users thinks that they need, but on a solution that solves the problem in a clean and simple fashion. His background is often a CPA or MBA with a minor in Computer Science (at least this is the case at BMI). But of cause things (or people) are not only black or white. Not all “programmers” - “just do it”. And it’s definitly not all CPA/MBA’s who can come up with simple and clean solutions. In some situations the PROGRAMMER is the one we need. I.e. for clean up jobs, debugging etc. He will also perform well in projects where he has a strong project manager. But I feel that the situation that Roy describes is not quite true anymore. At least not in neither Denmark or the US. Going back to the time before Financials (or even just a few years back in the US), then I recognize the picture Roy paints from both the US and Denmark. I think it’s an evolution of both the Solution Centers and the product. Just take a look at Navision Financials. In version 1.20 (US) it had 264844 lines of code. In version 2.60.E there is 391848 lines of code (and that’s without both Advanced Distribution and Manufacturing). The system has become much bigger and complex. This requires higher skills. At the same time most Solution Centers has both grown and adjusted their staff to the current picture. Many NSC’s where started by i.e. an accountant with a little computer/programming skills. Taking another subject such as documentation, source control etc. then I don’t really think that the “programmers” are so much blame as Navision. The system is simply not created to be “user friendly” towards the programmers/developers. Just take a look at the lousy debugger. The functions in this area are simply not good enough and doesn’t invite the programmer to do any effort. We had the discussion about the documentation on NOLUG before. But we never really came to a conclusion (the thread simply died… - who will start it again?). Because I don’t think it’s that we don’t want to do documentation - we just want to standardize it - so that every solution center/developer doesn’t make his own standard. Best regards, Erik P. Ernst, webmaster Navision Online User Group PS: My own background is in accounting/management with a formal computer education at a business college. I primary worked with Turbo Pascal and COBOL.
To come back on the ‘lack of programming skills’: Could it be that the C/AL language isn’t interesting enough for ‘real’ programmers? As a programmer I think Navision doesn’t offer enough opportunities to ‘create’. It is all about adjusting and modifying. Anolis Sittard Netherlands
I think you’re right here. It’s mostly adjusting and modifying (although sometimes really big adjustment and modifications). And if you don’t feel this as creating enough and the fact that you can feel the joy when what you did is really making a diffence for your user then yes (and then mayby you should move from Attain/Financials to Axapta). But another thing is that I don’t really think that we really miss the hardcore programming skills here. Programming skills of cause are required and needed, but if I can choose between someone with a background of 5 years programming and someone with a background of 2 years programming and a background as CPA or MBA, then I know I would take the later. Best regards, Erik P. Ernst, webmaster Navision Online User Group
Thanks Erik that makes me a Navision Developer. I trained in VB went straight into Navision, my first real IT job, no degree only real life working practices to fall back on. What do you need? To be able to understand the flow of data. What effect your changes have and why. To be able to think on your feet, to come up with a timely workable solution. There is no bible of Navision programming code, it is written by different developers as you can see by the different styles, no comments of any worth from N/S. So we have to find and fix the bugs, that can’t really be taught well unless the Developer understands what he is reading. In the recent Sevice pack 3 for NAD we found a lots of Bugs in the new code! As a Developer I would rate myself high in the UK and I have only needed to code in Navision for the last 6 years! David Cox MindSource (UK) Limited Navision Solutions Partner Email: david@mindsource.co.uk Web: www.mindsource.co.uk
What is good Navision programming? What’s quality? How to you attain good programming and quality in your project? I don’t think it’s your education that is most important. The most important are that you have rules and a methodology how you are making changes in Navision and get quality. To make programming in Navision you most have at least two skills: Product skills (How does Navision work) and programming skills. In my opinion, product skills are the most hard to get. My top – 5 in good programming: 1. Documentation, both internal and external. 2. Version handling, keep tracking of changed objects. 3. Testing, Testing, Testing…and Testing. 4. Add function, Avoid to change Navision’s function. 5. Newer “hardcode” data. And before you start coding, you most have the plan (design) finished. Let us have a new topic discussing methodology, and how we will get quality in our project!!! Per.Bay@navigera.com Product Manager www.navigera.com
It’s once again nice to see how friendly we are. Imagine: A new poster goes to any forum of professionals for the first time and starts his very first posting in the sense: “90% of you are incompetent”. I guess he would be eaten alive Nevertheless, from my own experience I have to confirm that Roy is right. I had programmed 17 years (started with 16) with about a dozen languages and had my software engeneering diploma 6 years in my pocket before I started with Financials in 1996. From 1987 to 1996 I had developed ERP and financial applications from the scratch (Pascal / Delphi) so I knew both sides Programming and accounting well enough before I started with Fin 1.1. Currently I am mostly working as trouble-shooter which means that often enough I have to save projects completely spoiled by incompetent programmers and many times I was looking at the code and felt ashamed to what kind of people Navision was granting a developer license . Even though bad programming (of others, of course) is my bread and butter I’ don’t know whether I would fall in the category of Programmer or Developer. I see myselfes more as a programmer even though I understood about the importance of documentation and change-management. (see new topic in Developer Forum : “Change Management”) After all I don’t know if the initially mentioned figure of 90% non-programmers is realistic. But there’s one thing for sure. It does not apply to this forum. You will find the best professionals in this Forum and I’m proud being a part of it. ------- With best regards from Switzerland Marcus Fabian
Main point of difference of programming in “genereal” languages and C/AL is that the latter one is dedicated. In many cases, “programming” in Navision comes down to adding a few lines of code to an existing object. How to code is fairly simple, but what to code needs a thorough understanding of Navision to know where to add those lines! And when you have that knowledge, you don’t really need extensive documentation on the changes made by others, as long as the code itself is clearly marked as a change or addition. When it comes to more complex additions and special functions, I personally prefer to read the functional requirements, rather than an extensive description of all objects and code. In fact, there’s a risk of “over-documenting” changes on changes on changes, which (to my opinion) is more confusing than clarifying. Have been involved with projects where the pile of documents had grown to over 10 cm height. When you step into such a project by the time the code is at accepted-for-go-live stage, nobody starts studying that history book anymore. Probably 90% or more relates to issues from the past (just like extensive lists with solved bugs) and are of very little value for understanding the current situation. I do agree, creation of a good set of documentation is needed. But there’s usually not enough time available to create it in a proper way, as by the time one project is completed the people with the overview of it (which you need for writing docs in the right context) are directed to the next project… John
John really hit it here. Navision Financials 4GL type programming is really so simple that code documentation is not needed. The complexity of the whole system on the other hand sets other requirements to the documenation, then with traditional 3rd. generation language. But I would even go so far to say that even the worlds best functional designs is worth nothing compared to the small and user-written users manual. The user-written is important - because this is a description of how the system “really” is used. Most supers-users I know create such a manual. Partly by own notes, partly by the one page description I usually delivers and partly be copies of pages from the “real user guide”, all with the users own notes attached. This manual is worth everything when evaluating the implementation and prepare to upgrade. All documentations of MODIFICATION BEGIN / END is useless in my eyes. Because even a simple compare program like MS WORD can document this to me. But what is worth something here is to have the MODIFICATION # in this code, because then you know that you can freely remove the modification when not used anymore (as per you functional documentation compared to the user-written documentation). Best regards, Erik P. Ernst, webmaster Navision Online User Group
quote:
John really hit it here. Navision Financials 4GL type programming is really so simple that code documentation is not needed.
I disagree with both of you (Erik and John) at this point. I believe that it is necessary that you at least find the place(s) where changes have been made. If you take into consideration that it will be another programmer who has the priviledge to upgrade your code to a newer version it might also be interesting for him to know why you have made a particular change at this very place. After all it costs less time for you to insert an appropriate comment than it would cost a programmer to figure out why you did this particular change. ------- With best regards from Switzerland Marcus Fabian
Marcus, It’s not that I think that the programmer should not document his changes. I just think that this documentation - especially if it’s only a “XX MODIFIED THIS 2001.07.10” - which is very common - is not worth very much. But when you hold it together with the functional documentation, and this has a link to the changes, then it’s worth something. The other change documenation is not more then what you can create with the merge tool or MS Word. Best regards, Erik P. Ernst, webmaster Navision Online User Group
quote:
Originally posted by Admin: Navision Financials 4GL type programming is really so simple … [/b]
NO, NO, NO. It is PRIMITIVE !!! The documentation problem becomes from there !!! It is good enought for simple modifications. But if you try to make more complicated solution you will stuck. C/AL is very limited language and have VERY HARD readable linear structure. All programmers at C/AL and NF studies feels very uncomfortable. Now days programmers experience starts from OOL, they never used such archaic things like BASIC or FORTRAN. C/AL ,it’s pity but it is, such programming langue. I can’t say that C/AL is OOL. You all know how is hard read modifications made by another programmer. You need browse all code. In OOL you should browse only obj derived by this modification. So, OOL skills is useless in NF. Navision employers advertisements should sound: - a skills in OOL is disadvantage.
I think it imperitive that a developer listen to the whole problem before offering a solution. I consider myself a analyst first and a developer second. As to the Accounting vs. programing backgroud issue. Bottom line: How often is the actual ACCOUNTING system modified? In my experience, rarely. The rules are to set in stone. Most mods revolve around enterprise wide solutions. So, I’d have to say that a experienced programer with a working understanding of accounting would be far better than an accountant with a working understanding of programing. I have seen examples of code that are just flat bad. Hard to follow, bad logic, and slows the system down. Bill Benefiel Manager of Information Systems Overhead Door Company billb@ohdindy.com (317) 842-7444 ext 117
quote:
Originally posted by db: It is good enought for simple modifications. But if you try to make more complicated solution you will stuck. C/AL is very limited language and have VERY HARD readable linear structure. They never used such archaic things like BASIC or FORTRAN. C/AL ,it’s pity but it is, such programming langue. I can’t say that C/AL is OOL.
Having worked with Navision’s limited language, I find that there is not much that can’t be done, bearing in mind what the product is meant for! Accounting! As for BASIC, well it is a requirement for any programming language, wich ones dont have nested loops, begin ends, do until, case of & if then else’s? you can create a lot of things these days with a wizard, but if you have a code problem, you must be able to understand what the wizard has written for you! If you can’t get to grips with the basic code structures you will never be a programmer! David Cox MindSource (UK) Limited Navision Solutions Partner Email: david@mindsource.co.uk Web: www.mindsource.co.uk
quote:
As to the Accounting vs. programing backgroud issue. Bottom line: How often is the actual ACCOUNTING system modified
In typical project, I change probably 2-5% in within the ACCOUNTING part, 10% in Vendors/Customers and 50-80% in Sales/Purchase -header/lines and item ledger. Therefore knowledge in ERP is more important than in accounting. Agreed? ------- With best regards from Switzerland Marcus Fabian
quote:
Originally posted by db: All programmers at C/AL and NF studies feels very uncomfortable. Now days programmers experience starts from OOL, they never used such archaic things like BASIC or FORTRAN. C/AL ,it’s pity but it is, such programming langue. I can’t say that C/AL is OOL. [/b]
I totally agree with that point. Looking on how easy it is for programmers “fresh” from the university (no matter which country), it is much easier for them to start programming in Axapta which uses a more “state-of-the-art” programming language (X++, the name only!) than NF. I can say that I’ve programmed in XAL, Axapta and Financials. All have their advantages against the others, but overall I would say with Axapta a programmer can do most. Helmut Wimmer Columbus IT Partner Austria NCSP NCSD