Collaborative/team labview coding - any tips or advice?

[PA-Paul]

As a company we've been using labview for a while to support various products, and now we're going to be trying to improve our work by implementing more of a collaborative approach to roll out some new versions. But we're not traditionally a "software company" so are starting to look at how we can do this from a "process" point of view, so I was just wondering if anyone here has any particular hints/tips or advice for where team members may be working on the same bits of code, how to avoid conflicts etc etc. IF there's any useful literature or resources that may give some insight into this area would also be gratefully received!

 

For info, we're planning to use mercurial for source code control, but havent previously gone as far as integrating SCC into labview (we've previously used SVN, and managed commits and checkouts through tortoiseSVN, but never used locking or similar as in general people werent working on the same bits of code). Not sure whether we would this time either, but will consider it if it is genuinely useful.

 

Thanks in advance.

 

Paul

 

 

 

 

[hooovahh]

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.