What kind of errors are you seeing? What do you mean by "stability"? Does the program actually crash?
There are actually two quite different issues involved: (1) Code design, maintenance and management: Shane and Ben already gave excellent answers for that. (2) Code performance and stability: >From your question, it seems you are struggling with errors and stability. This could indicate fundamental flaws in your programming approaches that prevent peaceful code coexistence as soon as a few modules are running concurrently. Some mistakes I've seen: -- Every module is "King of the world", polling for e.g. parameter changes as fast as they possibly can. Each tries to consume 100% of the CPU doing basically nothing. Example, looking at one of your ealier works <a href=http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000070D60000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0>HERE</a>: You have two FOR loops that have no data dependency, thus both run in paralell. The first loop is timed and occurs at a nice peaceful pace. The second loop runs as fast as it can, consuming <b>all</b> CPU, mostly reading the same value over and over and over again, each time re-doing what it just did. -- Race conditions where several parts of the program read and write to e.g. globals and locals and the sequence of events is unpredicatable, e.g. one parts tries to read a varable before the other part wrote to it, one part is writing and another part is erasing at the same time, etc. Strictly limit the use of local and global variables, they have limited purpose in the UI part but should not be used to shuffle data between different parts of the programs (as you did in the above quoted example),stick to wires whenever possible. Dataflow is a powerful concept. Breaking the dataflow makes the code unpredictable. A well designed LabVIEW program has no size limits. There are huge projects with hundreds of subVIs that run without any problems. I'd be happy to look at your code an scan for some common mistakes.
