‘Software that makes Software Better’ Economist Article

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.

New Software Engineering Tools for LabVIEW

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.

Architecting an Application to Avoid Spaghetti

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

Is LabVIEW a Programming Language?

Is LabVIEW A Programming Language?

Yes.

As a LabVIEW fanatic and enthusiast, I commonly field this question from customers and text-based programmers on a regular basis.At first glance, graphical programming appears abstract and so radically different from C and similar languages, that for many it’s hard to grasp how this grid of wires and colored blocks could possibly represent code.

While studying for my degree in computer engineering at the University of Missouri, I regularly programmed in C++, Java, and spent many long hours in labs going through the painful process of writing x86 assembly and even VHDL.I was also an avid web developer and had written many programs in a combination of HTML, PHP and Adobe Flash for a research lab at the school.Sadly, I had never used LabVIEW or graphical programming, but I did have one friend who kept egging me on to try it out.He claimed it would make my life much easier and that I could do all the same things I was already doing in a fraction of the time.

When I finally learned LabVIEW after beginning work at National Instruments, it was like a whole new world had opened up to me.It all made so much sense and I found myself wishing I’d listened and saved myself many all-nighters in college.

If you look back at 1986, the year LabVIEW 1.0 was released; graphical programming was a part of the natural progression. Apple had just announced the first graphical user interface ever for the commercial market.The use of computers had previously been entirely through the command-line and it seems logical that only text-based programming was around up until then.

Enter graphical interfaces… enter graphical programming. It was simple at the time, but the concept of dataflow made the representation of information and the relationships between operations to be performed much more apparent and easy for someone without a programming background to understand. It took off and became the foremost tool for anyone who wanted to control a bench top instrument and perform analysis in software.

These days, LabVIEW has evolved dramatically.  The abstraction LabVIEW provides still enables scientists and engineers to solve complex problems without worrying about lower-level details, but it still has the ability to control more granular aspects of your application and push that same graphical code down to the pin with FPGAs and embedded targets.What would’ve taken dozens of pages of VHDL can now be accomplished with just a few simple VIs in graphical code.LabVIEW is object oriented and open; developers can re-use libraries developed in .NET or other languages.Users can build professional, end-use applications for commercial re-sale.

The flexibility of the development environment even allows users to combine different models of computation within a single application.Dataflow can be combined with text-based *.mfiles or tools like Statechart to take advantage of the strengths of every paradigm.All of these different models of computations are compiled by LabVIEW into a single binary.

Because of the abstraction that is inherent to graphical programming and the investment we’ve made in the compiler, LabVIEW is even smart enough to perform optimizations in the background that result in performance that can often exceed that of text-based counterparts.This is especially true when optimizing applications for multiple cores, which is a growing concern as the personal computer continues to offer consumers more and more cores within a single machine without any significant gains in clock frequency.

At National Instruments, we even develop many of our software products and a large portion of LabVIEW itself in LabVIEW.For those of you who use Vision Builder, you’re using a LabVIEW application that spans roughly 5,000 VIs and is developed by a team of about 3 individuals.The fact is that LabVIEW is a programming language in every sense of the word and it presents users with more options and more flexibility than other monolithic environments.

Why do so many people still refuse to believe LabVIEW is a programming language?Perhaps after 23 years of development, LabVIEW is still just that far ahead of its’ time.

Share your thoughts on LabVIEW as a Programming Language!  Leave a comment below.

Great Resource for Learning a Common Architecture for LabVIEW Applications

Anthony Lukindo wrote an excellent article on expressionflow.com that explains how to utilize a queued state machine architecture with multiple producer / consumer loops.  The example he uses in this article draws from several of the fundamental design patterns that should serve as the building blocks for almost any new LabVIEW application (see image below).

If you’ve never seen them, make sure you review the design patterns that ship inside of LabVIEW as starting points for your applications – even simple ones.  You can navigate several Frameworks for development by clicking File >> New in LabVIEW.  The dialog that will appear is shown below.  Note the descriptions for each design pattern under the image on the right.

.

If any of you want to add your own design patterns to this dialog, you can.  This is potentially useful for groups of developers who would need to use a common, custom template regularly in their work.

To add a template, follow the pattern used for the existing patterns, which can be found here: C:\Program Files\National Instruments\LabVIEW 8.6\templates\Frameworks\DesignPatterns

This should include a png thumbnail and *vit template file.  Don’t forget to enter descriptions in the VI Documentation Property so that users will know what they’re getting themselves into!

Friends don’t let friends code in LabVIEW without the Project Explorer

Since this is my first blog entry, I feel it’s only appropriate that I begin with a discussion about how to start developing a LabVIEW application. These days, it’s not uncommon for some of the more complex LabVIEW applications to span thousands of VIs, which can pose a number of challenges if not given proper thought. What many don’t realize is that they can simplify their life and perhaps keep more of their hair by knowing how to use some best-practices combined with some of the latest tools in LabVIEW.

And this is true for all applications, large and small – be it one developer or 50.

The nature of graphical programming offers scientists and engineers a clear advantage when it comes to reducing development time and rapidly prototyping complex systems that need to interface with hardware. However, as a result, many jump directly into writing code without really giving proper consideration to some of the more mundane practices. Is this you? Have you ever thought to yourself…

· “My files are so disorganized – I don’t even know if I’m working on the latest copy of my code!”

· “Oh no, someone else overwrote all my work with their changes – I just lost a week’s worth of work!”

· “I’m too scared to rename or move subVIs because LabVIEW will never find the right ones and I’ll have to re-link them all!”

· “I want to compare my latest changes with a previous version to examine exactly what the differences are!”

If you’re anything like me, you’d probably rather be coding in LabVIEW than thinking about any of these things, but I’ve seen too many developers paint themselves into a corner by ignoring some of these until the last possible second. This is not an exhaustive list, but for the sake of today’s entry, we’ll keep it simple.

For anyone reading this that comes from a Computer Science or Software Engineering background, you’ve probably already heard of SCM, or software configuration management. For those of you who have no idea what I’m talking about, this just refers to a combination of tools and practices that developers have been using for years to avoid some of these common problems. I’m going to discuss some of the tools that you can take advantage of in LabVIEW.

Perhaps the most fundamental and important tool for any and all LabVIEW developers is the Project Explorer. Those of you who have just recently transitioned from 7.1 or earlier may still be fighting adoption, but hear me out – this tool was designed to make your life easier – you just have to know how to use it.

The Project debuted with LabVIEW 8.0 to mixed reviews. For many who had grossly outgrown using their operating system’s file browser (ie: Windows Explorer or Finder) to manage all their files, the Project Explorer was a welcome relief and had a lot of potential. However, as with any completely new features, there was plenty of feedback and discussion on what could be improved.

Fast forward two years. LabVIEW 8.5 came out in August of 2007, and with it came a revamped version of the Project that incorporated much of the feedback we’d been hearing from you. It is this version and all the latest features that I’m going to be discussing in this entry.

This is a screenshot of a Project in LabVIEW 8.6 that happened to be open on my computer while writing this blog. It’s true – I code in LabVIEW for fun whenever I can, but I always use the Project and source code control (note the checkboxes). Friends don’t let friends code without the Project.

I have a golden rule that I preach to all LabVIEW developers who are just starting out with the Project: “Think of the Project Explorer as an opportunity to tell LabVIEW: ‘here are my files – this is what I intend to use in my application – nothing more, nothing less.’ By doing this, LabVIEW is smart enough to help you make informed decisions and manage your application.” To clarify, you can and should use the Project to manage all of your files – not just the VIs. Note that in my screenshot I have VIs, as well as PDfs, videos, DLLs, documents – anything and everything related to my application.

So what exactly can LabVIEW’s Project Explorer tell you if you use it correctly? It can show you your entire system – including all the hardware targets and build specifications your project uses. It can warn you when you’re potentially using the wrong subVI. It can tell you when moving or renaming a file will change a link from another caller. It can instantly tell you when you’ve added a new file on disk. It can tell you when someone else is modifying a file and help you track down the latest version of that file. It can show you, graphically, the differences between your revisions and the last changes someone else made (also known as ‘diffing’). The Project Explorer can even tell you if you’re breaking my golden rule (subVIs you haven’t yet added appear in a flat list under dependencies).

For those of you scratching your head at source code control (SCC), I’m referring generically to third party tools that are commonly used for large application management. They essentially serve as an intermediate layer between you and the centralized storage location for all your code. You, as a developer, communicate with SCC by telling it things like “I’m going to modify this VI.” Through this exchange of information, other developers can then be made aware of potential changes, which avoids overwriting work and helps the rest of your team know when changes were made and who made them. SCC is beneficial even for individuals who just need to keep track of all of their revisions. I myself keep a Perforce server on my laptop which I use to store and manage all of my side projects (Perforce is free for individual use – check it out at perforce.com).

Interested in learning about how to set up the Project Explorer to take advantage of all these features? You can find technical details on all the topics I’ve mentioned here and more on this wiki: Managing LabVIEW Application Development in the Project Explorer. This guide provides best-practices and technical how-to’s for using the Project, so be sure to check it out and let me know if you have any questions or feedback.