Skip to content

Are You the Dynamics NAV Developer Type?

Hello, My Name Is Developer

You may have heard that being a Dynamics NAV developer is smart career choice. While it may sound appealing, what with the high-earning potential and in demand workforce, but it takes a specific type of person to be a good Dynamics NAV developer. There are ways to know if you are the Dynamics NAV developer type. So read on, or check out our handy infographic.

Do You Enjoy Lists? Long Lists?

The Development Environment is where developers live, breathe, code, and problem-solve. It houses every single element, or “object,” within NAV, into the millions. So why is this Object Designer list so extensive? At a glance:

  • Objects 1-9999 are developed in Copenhagen, and are used worldwide in NAV programs
  • Objects 10000-49999 are specific to a country, like sales tax modifications
  • Objects 50000- 99999 are customer-specific. This is where the developers create pages and action-items from scratch
  • Objects 99999+ are add-ons or system tables that control user configurations, permissions, and other internal workings

Does C/AL Code Intrigue You?

C/AL is not the enemy, but rather, an ally in NAV development and customization. NAV developers actually avoid writing code whenever possible, and rather try to modify NAV’s original objects to fit the client’s needs. A few essential elements of C/AL code include conditional statements, loops, and code syntax. Luckily enough, the written code is filled with simple words to direct the process, such as ‘if,’ ‘then’, and ‘end’ all as part of conditional formatting.

A conditional statement is a logical sequence that organizes and directs the code’s action. We use phrases like this in everyday language. For example, “If I leave at 8:00, then I will arrive late to work.” See the flow chart below to identify common conditional statement words used in C/AL code, as well as a sample of conditional flow in NAV’s development environment.

common conditional code in Microsoft Dynamics NAV
Figure 1 - Common Conditional Coding in C/AL

To process data automatically and to keep code concise and effective, loops are included. Loops are a sequence of instructions that are continually repeated until a certain condition is reached (the end of a list, a number hitting zero, etc.) To keep the loop running, a piece of the code within the loop is “replaceable” by any new data that enters the system.

When saving a Codeunit, it is likely that several error messages will emerge before allowing you to exit. Many of these will be referred to as “syntax errors” essentially formatting typos within your code. Those classic squiggly red underlines will show you where your error lies within the code, but it is up to the user to determine the cause of the error. These syntax errors can be a bit frustrating, but are usually minor punctuation modifications, like adding a semicolon at the end of a line or making sure that your brackets are consistent.

Because of C/AL’s easy-to-read format, ability to continuously process data, and syntax aid, clearly, C/AL is meant to be loved, not feared.

Are You Patient? Very Patient?

Dynamics NAV developers can spend hours, even days, tackling those annoying error messages before their work is complete. To reduce bugs and problems on the front-end, developers have to test, and test, and test again. There are two types of testing: manual and automated.

Manual testing, confirming the functionality of the code in the development environment by hand, is effective, but does not consider potential adverse effects on other elements of the system. Additionally, the developer is testing with a bias, perhaps adjusting their process to ensure that the code works. Therefore, in a manual testing scenario, a third party tester is ideal.

Automated testing is a computer-run process that can test codes at incredible speeds and catch bugs that could limit the code’s functionality for the entire system. Although automated testing costs the client more upfront, they will likely save money in the end avoiding hourly developer costs for bug fixes. However, even with automated testing, manual testing may still be necessary to ensure proper functionality and client requirement fulfillment.

Do You Believe in Functionality Over Perfection?

From a development standpoint, functionality likely takes priority over quality. However, during entire system upgrades, there will likely be errors that go unnoticed. Because testing has diminished returns, when a client would be satisfied with the functionality of the product, the development team is likely to Go Live with a product, even if it is not perfect.

The ERP industry is an exciting field and being a Dynamics NAV developer can be a smart career choice and may be your calling. Just make sure you know what you are getting into before making the leap and feel free to share the infographic.

ArcherPoint specializes in Dynamics NAV solution designdevelopment and upgrades. For more on how ArcherPoint and Dynamics NAV can help you advance your career, contact us today.

 

Blog Tags: 
Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube
Get Help Now