Leaderboard

Yes SCC is a must. In my opinion LabVIEW works best with the Lock, Commit paradigm instead of the Commit Merge. Basically the concept is that you talk to a central server and that server only allows a file to be edited by one user at a time and can't be edited by anyone else until that user is done with that file. SVN for me has been a pretty good fit for that type of work flow, and using tortoiseSVN is the most convenient way of doing that. That being said Perforce, along with a plugin allows for explorer integration. I only used Mercurial once, I was under the impression it was a merge paradigm. After SCC I'd say some kind of code review process. Have your best developer or two champion a pilot program where you run the VI analyzer on someones code, and then discuss the improvements it suggests. These developers should know the difference between perfect code in the eyes of VI Analyzer, and code that is acceptable. By that I mean ignore the errors that can be justified. That will help with some kind of standardization of code, and help train newer engineers with techniques they should be trying to use. After some time you'll notice each user will start to develop their own collection of coding nuggets. VIs they commonly use that do some task well and has been tested on several projects. After you see some ad-hoc code sharing taking place you should think about a formalized reuse library. At first you want to make it as informal as possible to encourage usage and collaboration, while not being so loose that code quality falls. VIPM is a great tool for this and honestly the only way I would want to implement a LabVIEW reuse library. You can do a bunch with the free version but pro might be needed for a few developers, or everyone depending on your usage. Virtual Machines might come next. A sandbox environment that can isolate projects from one another in a way that ensures no accidental saving of a LabVIEW 2009 in in 2015, or using DAQmx 15 on a project that hasn't been tested with those drivers. Just like reuse you can start with a basic setup with just a VM with each version of LabVIEW, or a VM for each project. There are also tons of advanced tools taking snapshots of projects keeping file size to a minimum. VMs are optional of course, but then again so is SCC to some. Depending on your needs you'll want formal documentation, and this may come at any time. A requirements document stating what the software should do, a design document made before coding begins and is updated as the design changes, and possible test documents showing that the code you wrote was what you wanted, and that the software does what it was required to. There's lots of other harder to quantify things like a good mentoring environment, clear leaders in the company like a Chief Software Architect who can plan long term goals, encouraging going to local user groups or other training opportunities, etc.

Also instructions on how to reproduce. If they can't do that first you won't get far.

I'm excited to announce that Lua for LabVIEW 2.0 for Windows has been released. Please go to http://www.luaforlabview.com to find out more about this. This release supports the 32 bit and 64 bit versions of LabVIEW for Windows. Support for other platforms including NI relatime targets will follow shortly.