In
addition to Idea Exchange, I think NI needs to pro-actively look at what it can
do to make LabVIEW programming much more efficient, requiring few mouse clicks,
less time looking for functions, and most important, be designed in such a way
that it lends itself to doing things “the right way”.
I
regularly see new LabVIEW users, and most have had no formal introduction to
the language. They are happy with the
ability to quickly get things done, and frustrated after a couple of weeks,
when their productivity drops to zero or below as the programming style does
not scale well. This often results in LabVIEW getting a bad reputation, and in
much of academia it is known as the language which results in messy,
unreadable, undocumented code.
I
will try to rewind my mind to when I was in that same state, and with the help
of a few anecdotes suggest a process that NI perhaps could adopt to improve everyone’s
efficiency, and give greater success for first time and experienced users.
When
I meet frustrated first time users I have two simple questions: Do you use TypeDefs, and do you know what a
LabVIEW state machine is? About 90% say
no. Quickly they confess that their
programs get overwhelming, are hard to maintain, and do not scale. They have locals and globals and sequence
structures all over the place, trying to make LabVIEW behave. And it won’t, for reasons you guys well
understand.
My
proposal is as follows, (and this is a supplement to the LabVIEW Idea Exchange)
Short
Term Fix:
- NI produces ten Short, well-produced You Tube Videos that give a
clear, concise introduction to the language and core things you must know to be efficient and
successful. Distilling the info into “must
know” stuff, and heavily promoting this, is vital to creating short term
success. These videos should be carefully scripted and reviewed by “pro’s” and beta
tested on LabVIEW virgins to ensure that key concepts are successfully
presented.
- Promote the living daylights out of these. Have the links in LabVIEW splash screen and
Help menus.
Longer
Term Fix:
- Proactively
interview LabVIEW users (and look over their shoulders) at different skill and
success levels (including successes and failure). List the stumbling blocks to efficiency. Quantify each of these and Pareto order them
to start saving LabVIEW programmers time and money.
- Measure typical tasks in terms of time and complexity for the
different skill levels of users. For example:
- How long does it take to create a TypeDef? A cluster TypeDef?
- How long does it take to create a new VI, complete with error
handling/terminals, icon text and artwork, clean diagram, etc?
- Look at the number of mouse clicks, the context shifts between
keyboard and mouse, the levels of hierarchies traversed in menus.
- Quantify the collective cost of a given inefficiency for the
entire LabVIEW community:
-
i. For
example, if a LabVIEW user waits 10 seconds for the properties page of an Enum
to load, and this occurs 50 times in the course of a small project, he has
wasted a total of 500 seconds. Estimate
how many users have the same waste: let’s guess 100,000. Collectively this gives an annual waste of
about 14,000 hours or seven man years in the LabVIEW Community. With a loaded cost for an engineer of well
over USD 100,000, this is a waste of one million dollars per year, for just
this one inefficiency! i.e. a more scientific approach to user efficiency would
give some shocking but useful metrics.
-
ii. To beat
a dead horse, every LabVIEW second wasted is multiplied by the huge user
community.
- Start an internal campaign to kill wasted motion and waiting
time from the end user. Why is the iPad
so popular? Because it’s so incredibly simple, instead of OK/Cancel buttons for
every function and actually so incredibly fast for simple tasks. At NI Week last year I sat next to a guy with
a laptop, and with my newly acquired iPad in hand. I quickly checked my personal mail accounts,
corporate mail, 5 favorite web sites to see the day’s news, and was done within
90 seconds, long before his laptop was done booting.
- Establish benchmarks for how much typical activities must be
improved from release to release.
- Have program development benchmarks:
- Global benchmark: For example; LabVIEW CLD typically finished
after 3,5 hours instead of 4 hours, and the year after in only 3 hours.
- Individual task and
workflow benchmarks. For example, how
long should an Express VI take to load? Or How long does it take to find the
LabVIEW function to programmatically determine the Computers IP Addresses.
- Benchmark for learning particular LabVIEW skills and for find
LabVIEW information.
- Solicit input from the loyal LabVIEW community to participate in
this process.
Finally,
I would like to offers an example or three of how certain questions about
workflow and efficiency could be looked
at, and there are many:
- Bundle by name for a cluster input of a VI. Why does this take 5 mouse clicks instead of
one. And why must it be so hard for a
beginner to figure out how to do this? (Sorry R & D, I harped about this
one 14 years ago…)
- Why do I have to traverse four levels of right click menus to
find the Property Label/Text or a couple of levels to find the Value Property well
hidden in an incredibly long list of properties.. Why not study typical users, and promote the
8 or so most frequently used properties to the top level.
- Type Declarations: When a
front panel control or indicator is dropped, it corresponds to a type declaration
in a classic language. But when I want
to create a LabVIEW TypeDef, it gets a lot more complicated. The CreateTypeDef right click function
recently accepted only goes part of the way.
Why shouldn’t the user be able to just type the Label Text and be done
with it? And LabVIEW automatically
stuffs it in a control folder, applies changes, etc. Then let the Customize control function be
primarily oriented to cosmetic customization. And if we want to create clusters
of stuff, then just drag one control onto another, and LabVIEW automatically
creates a container (cluster) for both controls, highlights the cluster’s Labels
so that it immediately accepts keyboard entry for the name, and upon hitting “Enter”
it is automatically saved under that name and applied. Or perhaps also have a Control Browser (as a
tree control?) where controls are shown in their hierarchy, can be dragged onto
each other to create new clusters. I
know this stuff may be hard to implement, but it is the type of things that can
be real time savers.
My
gut feel is that the mechanics of using LabVIEW could easily be improved a
factor 2!!!
