1.1 LabVIEW Sucks | A Software Engineering Approach to LabVIEW

J. Conway writes , "LabVIEW sucks!" Yep, I was convinced that this stupid "picture" language I was being told to use was absolute rubbish. Tom, a colleague of mine, and I were working on a large Automatic Test Equipment (ATE) project. It was 1993, and I believe it was more luck than judgment that had led the management to choose LabVIEW over the other languages that were available at the time. My background prior to this was all text based, certainly not PC based. I absolutely hated this language, as well as Windows 3.1.

I have also encountered many other software engineers who hate LabVIEW (hate is a very strong word, but it certainly seems to sum up their feelings). So, why did I have such a hard time, as well as many other engineers ? I think the answer is simple, it is very hard to program extremely badly in LabVIEW because you are forced to use the data flow paradigm. In general this means that all users of LabVIEW are being forced to program in a certain way. At least this means that all software written follows a certain pattern. To many programmers this becomes infuriating, but I think they, and earlier I, have missed the point.

Don't get me wrong, LabVIEW does not make a complete novice write superbly engineered code, quite the opposite (and hence one of the underlying reasons for this book). What LabVIEW does do is lay the foundation for how the software is constructed . For example, when looking at the world of C++, probably one of the most popular languages for the software engineer, there are many ways code can be written. If you are a C++ user you may be gasping with horror at this statement, but I feel it is true. Many people think of C++ as Object Oriented (OO), assuming that all code written is OO. This is not the case. It is quite possible to write software in C++ that bears little resemblance to any OO at all, because the engineer is not forced to use OO techniques.

What makes LabVIEW different is that you do not have an option to write software using anything but the data flow principle. In fact, if you tried really really hard you probably could get around this, but it would be too infuriating to take very far. This removes the flexibility to deviate from or invent your own system. Some may say that this stifles creativity; I say that they are talking nonsense . Any software is merely a tool for expressing a design, as a building expresses the design of an architect. What is important is how strong the software is, which can be compared to the cohesive components that make a building stay up. Imagine the total chaos if builders were allowed to use whatever materials they liked , bonded together in a manner that was left up to the individual. I think you probably get the point. When you look at the many software projects that fail, overrun , or do not meet the requirements, you can begin to see why it is such an advantage to work with underlying rules.

There are many other advantages to using LabVIEW, which will be discussed in later chapters, but before going any further it is important to grasp the concept of how a tool is used. Another big problem in the world of software is how the language is portrayed. LabVIEW has often been marketed as a software package that makes writing software easy.

Software is not easy. LabVIEW does indeed make easy things easy to do, but as with all modern languages once you go beyond the simplest of tasks the ease of software construction diminishes as a prerequisite for success. If you are only going to write the simplest of applications, then you probably do not need this book. However, if you are going to be involved in medium- to large-scale projects, the principles and techniques presented here should give you a fighting chance for success. This book presents nothing new, which is another point of immense importance. This book attempts to show you how to apply already well-defined software engineering principles to LabVIEW.

This is not a learn to program LabVIEW in two seconds book, or a bible, or an unleashed or advanced version; it is simply for engineers to be able to construct LabVIEW code with basic software engineering principles. This book is also not for someone who does not "buy into" the most important and underused aspect of software engineering, design. I do not intend to come up with a new way of doing things, just the right way. What is laid out in the following chapters is what I have put into practice in the projects that I have been involved in using LabVIEW. There is a big "aha" factor for me for a lot of what I present, and I feel that most of what I am attempting to show here will be of immense help.

The underlying purpose of this book is not to show tricks and tips on certain abstracted problems, but ways of constructing LabVIEW code from a proper design. If you do not like the sound of this, then put the book down and walk away because there is a lot more to come. As the title says, this book is intended as a guide to present items that I have personally used, chewed over, and hopefully come up with a way of tackling the issue. However, I am not arrogant enough (some may disagree ) to suggest that this is the only way, or in every case the best way, of doing things. I hope that the book will be an ongoing piece of work that builds a community of members who are interested in the advancement of software engineering within the LabVIEW arena. My intention is that this book will set in motion the continual improvement of how LabVIEW software is constructed by inviting as much constructive criticism as possible.

Top