What's a reasonable sized program?

Question

We've inherited a LabView program that comprises 119 VIs and 3 CTLs,
totalling 9 Mb.
The main VI is 2.6 Mb; its Diagram is about 2400x2000 pixels, which means
it doesn't fit on any of our screens.
Our experience with LabView has been with much smaller programs, as
prototypes. The actual production code was always in a text-based language.
Is this a usual case? Is this a big program for LabView? Do many of you
maintain bigger programs?

Answer 1

We've inherited a LabView program that comprises 119 VIs and 3 CTLs,
totalling 9 Mb.
The main VI is 2.6 Mb; its Diagram is about 2400x2000 pixels, which means
it doesn't fit on any of our screens.
> Is this a usual case? Is this a big program for LabView? Do many of you
> maintain bigger programs?
>
There are very large applications based upon LV, but the code you have
inherited sounds like it needs some work in order to be more maintainable.
A good amount of top-level diagrams is usually associated with user
interface. With control references, it is possible to place much more
of this code into subVIs, which ideally will cut down on code
duplication, but can at least add readability to the diagram and make it
come closer to fitting on the screen.
Probably a much more telling statistic on this program is the number of
bugs. Maintaining a working program is pretty straightforward if you
can assume that the stuff you are working with works. If the code is
quite buggy, then you are having to question IF the code works at the
same time as figuring out HOW it works. Typically, tied into this is
the number of globals in use. Race conditions concerning globals being
accessed helter-skelter are some of the harder problems to debug, and
the globals often tend to hide the true connections in the program.
If you are looking to clean this up yourself, the first thing to do is
look for the functional modules that sort of exist or should exist, and
start cleaning up the top level diagram so that the code is arranged
that way. Don't just make subVIs to shrink the diagram, but figure out
what is going on at a given point in the diagram and make the
appropriate changes so that it becomes more obvious and smaller.
Inheriting code is never easy. It usually seems to be made of too many
small pieces that hide what the program is doing, too few large pieces
that hide what the program is doing, or objects are named something that
doesn't make sense to you and lead you to make bad interpretaions. In
order to start maintaining it, you have to dig in and start to transform
things systematically either in your mind or on the diagram.
Greg McKaskle