How big is a big LabVIEW project?

[cebailey]

Andrey, thank you for this.

The Development Guidelines link seems not to work; it opens a blank page for me.

The Style Guidelines are very nice.

The Style Checklist I already knew, and it is also very nice.

The two Rules are perhaps the most valuable because it is pretty easy to tell if I'm following a rule or not, and see why I might want to.

The 12 steps is absolutely excellent. At least to me, it looks like a perfect statement of the right number of principles, written in a way it is impossible to cheat. I've read other stuff by this author which was excellent too. This is a splendid find for me!

As for your personal recommendations - I mostly like them, with just one exception that everybody else will agree with you on.

I do like to use flat sequences for the purpose of controlling execution order, in the situation where there is not already a dataflow relationship (other than error wires) that would control it. About a dozen times, people have kindly suggested that I use error dataflow to accomplish this goal, and it always seems wrong to me. A flat sequence makes a clear statement that the purpose of the arrangement is to control execution order, whereas wiring the errors does not. Ordering by error flow seems like a programming trick to me. It's using errors, which are one topic, to achieve an unrelated goal in timing, another topic completely. If there were no other way to control order, then hats off to anyone clever enough to think of using the error wires to do it, but given that flat sequences are available and are intended for exactly this situation, it is more clear and less surprising to use them. We should be able to think about what to do with error collection, and should have the option to change something so that it successfully and properly does what we want with the errors. But if we had been ordering with error wires, the code remains syntactically correct and yet suddenly doesn't do what we want anymore for reasons we weren't even trying to think about, which is perhaps the worst kind of mistake.

At least, that's what I think. I haven't found anybody else to agree. I'm going to officially guess that anybody else commenting on this point will also disagree with me.  Perhaps, as a kind of olive branch, a peace offering, we can all agree to gang up on anybody who uses stacked sequences. That seems like a nice compromise.

Thanks for a very good list of links and advice!

[Ben]

---

cebailey wrote:

.. I haven't found anybody else to agree. ...

---

Pssst....

Rumour has it that someone who uses a Teddy Bear* as an avatar agrees with you .

Ben

* That evil glint in his eye is there for a reason.

[Andrey_Dmitriev]

Development Guidelines attached to this post.

In the post above I mean Stacked Sequences only. If you have two-three frames (for example, for execution time control, of for separating two logical parts such Initialization/Run, then no big problem, but I have examples where 20-30 frames was used in stacked sequences, and this is just "hell" for support such code.

Flat Sequences are OK. Also read this Nugget from Darren about flat sequences

Andrey.

[F._Schubert]

Brilliant discussion so far, I have to throw some Kudos around.

For the first topic, projects are getting big somewhere on the 500-700 mark (as they not only are pure code but scale the same in terms of hardware wires that mess up,  bad documented interfaces for faulty external software, customer requiremement changes and burn-outs), and getting evil somewhere at 1000+. I think that metrics are fine at that level, as at this size, the various coding styles and architectures are averaged out, but I guess that the project scope (vision, high-speed daq, distributed apps over various targets) will have a major impact. I would be interested in knowing the scope of smercurios 3000+ app.

Now the design guideline topic, directly to cebailey, propably you could now really profit from Bloom's book ('The LabView style book').It really presents some good techniques and that's what you seem to look for.

About the error wire vs. flat sequence: I normally want code either to execute only if the upstream code did work (if the move command fails, I don't need or even want at all to wait until the position is reached) or I will want to have the code in parallel with some syncronisation points (e.g. via queue messages). I don't think the flat sequences are bad, but more like they limit my coding (as globals do, LV2/AE's are scalable -> just too cool).

Felix

[tst]

I know of a project that loads ~1400 VIs and has ~9000 dynamic VIs, although I don't know the specifics. Some of them are probably utility VIs and vi.lib VIs.

[Andrey_Dmitriev]

Just in addition, what is really important for big project - is architecture. I mean, if you have project growed to 1000+ where each VI depends from other VI without good structure, but like "spaghetti", then you will spend more time for bug fix and service than for development. If you have plans for grow, then it should be good planned before development start. You should go first into requirements and design phases, only then start with coding. For example, I have 1500 SubVIs in 150 libraries - few "core" or "common" and most of "satellite" libraries, which absolutely independent, so I can build my final application like from bricks.

One more point which I have learned from Frederick Brooks (The Mythical Man-Month - great book) is "Second system effect". I mean that engineers are very careful with first project. They know that they haven't enough experience.  But when project ready and works, then they can imagine, that they can do ALL... The problem, that they still haven't enough experience for big project. So, usually you should put your second project to the trash completely, and then start from scratch.

Here is an example of the project scope which i have done last year. This application can be positioned as medium size, or probably inbetween medium/big. 1500 VIs in memory (approx. 450 - core application, 500 - in dynamically called llb plugins, rest coming from vi.lib/user.lib).

Andrey.

[Ben]

---

Andrey Dmitriev wrote:

...

Here is an example ...

Andrey.

---

Andrey,

Could you please e-mail me at

bar@dsautomation.com

?

I'm wondering if we are cousins.

Ben

[cebailey]

So the Teddy Bear icon displays the state of AppreciatesExplicitTimeRelationships, eh?

The Mythical Man Month has long been a favorite and it is wonderful to see it come up here.

I have ordered Blume's book (not "Bloom").

What an excellent discussion for my interests - thanks!

[Elijah_K]

This really is a great discussion - it's always insightful to hear the community's perspective.  A number of you have mentioned topics such as source code control and application architecture, so I just wanted to point you all to a relatively new page that I'm hoping you'll find useful.  We've been working to provide a single landing page for content related to software engineering, which walks through each phase of development and provides a combination of white-papers, best practices and webcasts. Check it out and share your thoughts.

In my interaction with customers, I would say that a large applicaiton starts at roughly 1000 VIs and typically doesn't go too far beyond 5,000.  That being said, I have seen a very small number of applications that have exceeeded the 10,000 VI mark and they're all consistently getting bigger every day.  The good news for the community is that we recignize this, and we have been investing in tools such as Project Explorer to help you scale development for thousands of VIs and multiple developers.

Out of curiousity, what is the largest application you have ever worked on in terms of VI count?

Message Edited by Elijah K on 11-13-2008 10:19 AM

[Mr._Jim]

It's funny, because as alluded to previously, coding style causes a huge variance in the number of VI's.  For this reason I agree with those who disregard the number of VI's as an inaccurate metric.  I've been refactoring code lately that is, in my opinion, rather "large," but there have been relatively few subVI's and ginormous block diagrams that span acres, nested sequence structures, overlapping piles of structures, wires, and anything else along with other LabVIEW code practice abominations.  (Naw, I don't have a strong opinion on this matter! ) 

With reasonable coding practices, though, I agree that 700 has always been a magic number.  Why 700?  Who knows, but I remember staring at the load dialog on several occasions and subconsciously thinking, "723 VI's.  Yeah, this one's getting big."

For what it's worth...

Jim