We should liberally make backups of objects on which we are working. Always make a backup of an object before changing it. Make intermediate backups regularly during development. This allows recovery back to the last working copy.

If our project involves several developers, we may want to utilize a source control system that tracks versioning and has a check-out and check-in facility for objects. Larger projects should take advantage of the testability framework that's now a part of C/AL (see Testing the Application in Help - https://msdn.microsoft.com/en-us/dynamics-nav/testing-the-application).

Compile frequently. We will find errors more easily this way. Not all errors will be discovered just by compiling. Thorough and frequent testing is always a requirement.

When we are developing pages or reports, we should do test runs (or previews) of the objects relatively frequently. Whenever we reach a stage where we have made a number of changes and again have a working copy, we should save it before making more changes.

Never design a modification that places data directly in or changes data directly in a Ledger table without going through the standard Posting routines. It's sometimes tempting to do so, but that's a sure path to unhappiness. When creating a new Ledger for your application, design the process with a Journal table and a Posting process consistent with the NAV standard flow.

If at all possible, try to avoid importing modifications into a production system when there are users logged in to the system. If a logged-in user has an object active that is being modified, they may continue working with the old version until they exit and re-enter, then be greeted with the new version. Production use of the obsolete object version may possibly cause confusion or even corruption of data.

Always test modifications in a reasonably current copy of the production system. Do the final testing using real data, or at least realistic data, and a copy of the customer's production license. As a rule, we should never develop or test in the live production system. Always work in a copy. Otherwise, the price of a mistake, even a simple typo, can be enormous.

If we wish to check that changes to a production system are compatible with the rest of the system, we should import the changes into our test copy of the system and then recompile all of the objects in the system. We may uncover serious problems left by a previous developer with bad habits, so be prepared.