After a few weeks of vacation, I’m back in Austin and have some hot news for all you Large LabVIEW App developers out there.  Scripting is now officially available!

For all you ‘rebels’ who have been using scripting for years, you can now do so with a clean conscience.  Download the installer from this link and follow the instructions to activate your new scripting license.

For those of you who are unfamiliar with scripting, this is not to be confused with scripting languages like Python or Perl.  LabVIEW scripting exposes additional VI Server properties and methods that allow more programmatic control over the development environemnt.  Why is this valuable?  For an example of what can be done with scripting, check out JKI’s new Right-Click Framework.

So why didn’t we expose this sooner?  Scripting was initially developed for internal programming purposes, but was soon discovered by LabVIEW aficionados.  Concerns regarding forward compatibility and unsupported functionality were one of the largest reasons we didn’t make this formally available before now.  For now, LabVIEW scripting resides within NI Labs and is not formally supported by the Applications Engineering group.  To discuss questions, feedback or any problems, visit the API Community.

Distributing code and re-use libraries can be a surprisingly difficult task.  Luckily for us, our friends at JKI have come up with an extremely elegant and professional solution for LabVIEW called the VI Package Manager.  If you’ve never heard of this tool, I strongly encourage that you check it out.  In addition to making code management easier, VIPM lets you download all the OpenG libraries, which adds some very useful functionality to LabVIEW.

To understand when VIPM is especially useful, consider several common examples of when you want to distribute your code:

1. You have a set of common VIs that you want to re-use in multiple applications
2. You are working in a team-based environment and other developers need your code
3. You want to share a set of development tools with a colleague
4. You want to post VIs online for the community to use

These all seem simple enough, but now lets throw a wrench in the works with a few common tasks:

• Updating code – it’s common to make changes or updates to shared libraries during development.  All team-based environments should be using some form of source code control to track and manage changes from multiple developers, but it can still be challenging to make sure you have the right version of all the subVIs installed and in-use at the same time.

• Professional distribution – how do you share code in such a way that it minimizes the work required by the recipient?  Instead of having to move multiple files into the correct directory locations, everything is installed automatically and appears on the palettes.

• Dependency management – ever opened up an application on a new machine and discovered that it’s broken because you forgot some dependencies from a re-use library or a toolkit you forgot to install?

• Multiple LabVIEW Versions – how do you make sure that the updates have been made available in all versions of LabVIEW, and not just the most recent version?

As you’ve probably already guessed, these are some of the biggest challenges that VIPM is designed to help with.

There are two flavors of VIPM: the professional version facilitates creation of ‘VI Packages’ and the free version enables anyone to install and manage these packages.  You can download packages from a number of places online, or VIPM can automatically scan dedicated servers to see what’s available.  I’ve also spoken with a number of LabVIEW users who are using the professional version of VIPM to distribute code internally during development.

As an example, Simon recently posted a set of custom controls for use in LabVIEW.  Minutes after making them available, Jim had created a package and posted it on the document, which made installing them in LabVIEW a breeze.  A few clicks, and the swanky new controls were in my controls palette.

ni_lib_ni.com_inspired_controls-1.1.0-1.vip

These were updated a few times, and each time I just downloaded the package and VIPM took care of replacing the old controls.

Download VIPM and give it a try yourself.  Thanks to JKI for making such a great tool!

If any of you subscribe to Joel on Software, you may have come across this article where he provides a 12-step checklist for developing quality software. These recommendations are just as true of LabVIEW development as they are of any other programming language:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

In Joel’s opinion, if you can’t answer ‘Yes’ to at least 10 of these, you have serious problems with your development process that could slow you down and lead to low-quality code. I went through these with NI’s NPI process in mind and happily scored a 12.

As a LabVIEW developer, if you would like to share insights or feedback on any of these topics, we’re eagerly hoping to hear from you…

To anyone who is afraid or worried about upgrading, we hear you and we’ve made changes to help.  Back in January of this year, David Fuller wrote an entry on John Pasquarette’s blog  describing what we’re doing in R&D to reduce problems associated with upgrading.  To summarize:

• Our move towards an annual release schedule results in incremental changes and updates, which mitigates the risk associated with introducing several completely new features at once, as we did with LabVIEW 8.0.
• The regular release cycle provides more opportunities for guidance from customers as features evolve – consider the changes to the LabVIEW Project Explorer between 8.0 and 8.5 as an example of this evolution.
• Internal alignment across all teams means better coordination between all software products, drivers, and hardware

However, it’s important to realize that there is something you can do to help.  Try the Beta of LabVIEW 2009.  Upgrade issues are top priority for us - the trick has always been finding these problems, and for that we need your help. 

As of April 2nd, the entire platform of the next version of LabVIEW is now in Beta and available for your evaluation – this means all software, toolkits and drivers. 

As always, the new version contains new features that aim to improve developer productivity and application performance.  To see a list of new features and provide feedback to the community, click here.

Finally, for more resources on best-practices for upgrading your application, consult this guide on ni.com.

I read a great article in The Economist this morning entitled ‘Software that makes Software Better.’  This article discusses the growing role and importance of development tools for improving the quality of software and talks about the growing challenge developers face.

This article is proof of how far we’ve come in the last half-century.  We’re seeing a number of trends converge and software engineers are struggling to keep up.  Development times are shorter, team size is bigger, the criticality of the applications is increasing, the expectations for quality and reliability are greater, code has to be modular and re-usable, and on top of all this, developers are expected to learn how to use numerous, poorly integrated tools that claim to make everything easier.

I’ve had a number of engineers, especially those in the mil/aero industry, tell me that they spend a mere 20% of their time actually developing code.  This may be slightly over-exaggerated, but a study conducted by the Standish group revealed that this number was closer to about 30%.  The rest is dedicated to refining requirements, discussing work with teammates, documenting, unit testing, integration testing… you get the picture.

The good news is that we’re making progress.  As another study revealed, the Standish group “found that 35% of software projects started in 2006 were completed on time, on budget and did what they were supposed to, up from 16% in 1994; the proportion that failed outright fell from 31% to 19%.”

LabVIEW is being used in larger applications, with larger code bases, and larger development teams.  Of course, graphical programming inherently abstracts many of the common tasks text-based developers struggle with during development, and with a set of tightly integrated software engineering tools, we aim to automate and improve the experience of applying software engineering practices to LabVIEW.  If you’re interested in learning more about best-practices for software engineering with LabVIEW, visit ni.com/largeappsor go to ni.com/SoftwareEngineering to see a list of products that can help.

There is perhaps no more appropriate place to announce the arrival of two new toolkits for large application development than here in the Large LabVIEW Application Community.  The Desktop Execution Trace and Unit Test Framework Toolkits have been introduced to automate common practices for software engineering and help developers improve code quality.

The Desktop Execution Trace Toolkit facilitates dynamic code analysis for low-level debugging of applications during runtime.   The Unit Test Framework is designed for automated unit testing and requirements-based validation of software.

Feedback from users in highly regulated industries was one of the primary motivations for creating these products.  As we continue to invest in LabVIEW for large applications, we are benefited by feedback on these products and the needs of our users.

So to those of you who have had a chance to use these and similar tools, please use this community as an opportunity to share and exchange your ideas.  We look forward to hearing form you.

One of the most appealing things about LabVIEW is that you don’t need to be a computer scientist to write fairly large and complex software. For many, their journey with LabVIEW starts in school or at a benchtop with a simple application to quickly acquire some data. Once they’re hooked on the ease of graphical programming, it’s only a matter of time beforethe ideas start flowing, and pretty soon they’re off developing amazing applications like a mind-controlled wheel chair, the world’s largest particle accelerator, or how about a 3D Space Ship that flies through a starflied.

The problem is that the same approach people use when throwing together a prototype or a proof of concept will land them in a world of pain if they don’t ever stop and consider fundamental questions like, “how should I architect this application?” All too often, I see the tangled mess of spheghetti code emerge as the result of thoughtless, or ill-planned development.

For most people, their very first experience with LabVIEW leads to messy, un-readible code.  Even LabVIEW gurus have humble beginnings.  The expert G developer, D Natt, was kind enough to send me a screenshot of his very first LabVIEW program. Let the image on the right serve as an example of what not to do. If you find yourself wishing you had 8 more screens to see a single block diagram, or if your block diagram looks anything at all like this one, you may want to consider giving more thought to the architecture of your application. As an exercise, see how long it takes to determine what the VI on the right actually does.

It’s important to realize that spaghetti code is not unique to LabVIEW. As someone who started with text-based languages, I’ve seen plenty in all sorts of different languages. The difference is that it’s a lot easier to write graphical code that will run, even if it’s completely illegible. When the result doesn’t work correctly or yields unexpected performance, it can be very difficult to debug and many prefer to point the finger at LabVIEW rather than acknowledge their own lack of foresight or experience.

So lets turn our attention to how we can architect our LabVIEW application. Start with the main problem you’re trying to solve and figure out what the software needs to be able to do in order to be considered ’succesful.’ The criteria that emerges from this assessment will help you make informed decisions about how the code should be structured. This is, in many cases, the product of experimenting, prototyping and developing proof of concepts that highlight the areas of difficulty and help you understand what type of information or data will need to be shared between different ‘pieces’ of an application.  At this point, we need to take a step back and make sure we understand design patterns.

A ‘Design pattern’ refers to a template that serves as the building blocks for software. If you have an application that requires a responsive user interface, consider how many other developers have been faced with the exact same requirement. You’re not alone, and there’s no reason you should be starting from scratch. Design patterns are universal to programmers in any programming language. They save you time by helping you avoid reinventing the wheel and give us the solutions to common problems that have evolved over time to be the best, and most appropriate solution. If you’re new to design patterns, check out the File >> New dialog in LabVIEW (show on the left). This is a great place to get started with some basic design patterns that are very specific to LabVIEW. Be sure to read the descriptions to understand exactly what problemsthey can best help you solve.

I also recommend visiting expressionflow.com. Anthony Lukindo wrote an excellent, indepth article on the QSM-PC (Queued State Machine – Producer / Consumer) design pattern, which is a fairly common and very useful pattern for a-sychronous computations in a fairly large application.

For those of you familiar with text-based design patterns, AristosQueue posted a great article filled with examples of how to map classics like the Factory Design Pattern to LabVIEW using object-orientation.

The JKI State Machine also serves as another great template for developing clean code.

Architecting a high-quality piece of code ensures that it’s readible, scalable, maintainable and reduces the chance that errors or incorrect behavior will occur. I’ve focused a lot on design patterns, but don’t lose sight of the fact that just is one small piece of the puzzle. You’ll also want to think about how the application can be modularized and design APIs early on. Oh and of course, documentation is paramount.

One final word of caution: keep it simple and pick the archicture best suited to what you’re doing. But as always, have fun

I had a thread on the LAVA forums brought to my attention on the topic of ‘What is your LabVIEW application development process?, Best and worst development practices?’ This thread prompted an interesting discussion regarding some of the common challenges developers face when tackling a large application.

One of the primary goals of creating this group in the new NI community was to foster conversation and dialog amonst those of you working on these large LabVIEW applications and to share your insights on what you’ve learned from experience – both good and bad.  I’m excited to see that this same exchange is taking place in a number of different venues, including the thread that I stumbled across and the new wiki on LAVA dedicated to Software Engineering.  http://zone.ni.com/devzone/cda/tut/p/id/7117

Several people mentioned the difficulty of requirements management in this thread.  The consensus amongst software developers is that requirements gathering is a difficult art to master, but the fact is that it can be extremely costly if overlooked.  After analysis of 63 different software projects at companies such as IBM, GTE and TRW, we can actually put a number next to the ‘cost of getting it wrong’

The fact is that LabVIEW often falls victom to oversight of requirements as well as a lack of due dillegence for other software engineering practices due to the fact that it is so commonly used for rapid prototyping of small applications.  Too often, I’ve seen developers try to scale these initially small projects into much larger and more complex systems without giving proper thought to requirements and especially to code architecture.  Good requirements are typically generated as a result of iteratations between prototyping and documenting the findings of prototyping, which then lend themsleves to proper archiecture and better insight into how an application should be designed and help developers apply sound software engineering practices to ensure quality and reliability.

If you’re interested to learn more about requirements management with LabVIEW, check out some of these links.