Random Ramblings on LabVIEW Design

Community Browser
Showing results for 
Search instead for 
Did you mean: 

Re: Some Conclusions

Active Participant

Over the last 20 articles I've been discussing and thinking about design, methodologies etc. I think it's time to sit back in our smoking jackets, light up a cigar, pour a generous glass of brandy and have a bit of a recap. This is like a cheap episode of a TV series where they cobble together old clips.

My world view has been changed somewhat by the insightful input from you clever people. Obviously my world view is not going to be yours, but there is some useful stuff here I think.

So a few of the articles revolved around the concept of Cohesion and from this the discussion moved onto why our methodology doesn't give us the problems others have witnessed. Are all of our projects just inherently simpler or are we doing something others are not. Now this is something I have been really really thinking hard about and I have come to a conclusion. For us LCOD is a way of expressing our LabVIEW design with regards to Coupling, Cohesion and Information Hiding, because of this we are sensitive to communication paths, readability, abstraction. So if you just take the technique and design your components with no regard to how they talk to each other, the data they expose, the connectedness of their functionality you will end up with a poor LCOD design.

The exact same thing applies to LVOOP, you could conceivably make one big class, that contains all the data used by the program and has 150 methods that describe all the functionality of the program. This obviously would be a bad design but does it make LVOOP a bad methodology?.

The same will apply to actor framework I bet.

I think this demonstrates an over-riding interest in the community regarding techniques over actual design. This can be seen from the lack of comment and lower audiences for the more design oriented articles. (Cohesion for VIs and your State Machine, Databases with Jonny and Stevey, CODE Smell: if not EASY and not SIMPLE or not UNDERSTANDABLE=COMPLEX LOGIC!). Now personally I think the State Machine stuff is really something worth thinking about.

The other thing I have learnt is that use cases are very important when talking about methodology. I think some of the initial friction was due to the difference of the techniques for designing tools, compared to complete systems. Pretty much all of my discussions are regarding complete systems. For tools think DAQmx Tool Palette. From our perspective these lack cohesion, and this is absolutely correct. It is our job to take this non-cohesive, scaleable bunch of VIs and make them into cohesive modules (components, classes, actors)

If you're a complete stats addict (as I appear to be) you'd monitor the various numbers on the blog pages. As I understand it the #views increments every time someone lands on that exact page. To my amusement the page that gets consistent hits every week as if it has come from a search engine is the Universal Test Framework, an article making fun of the concept of a system that can test anything is now number 2 in the google searches for such a thing.

Oh if you want to hear the noises that come out of my face I invite you to jump to VI Shots (I never knew I sounded so cockney)

Anyways I hope you've enjoyed the last 20 articles.

Lots of Love



Thanks Steve this is a good one.Keep Random Rambling on.

Munch Love

Certified LabVIEW Architect
Certified TestStand Architect
Active Participant

I think you raise a great point, that an expert can describe a great software design approach/architecture/framework in great detail, but without a sufficiently broad/deep understanding then a developer could easily inappropriately apply the said advice. I've been there myself, and oft burned attempting to apply a framework I didn't fully understand at the time.

As in your blog, I can see that the Actor Framework is a great model to use and has wide reaching applications, but I don't have the kind of understanding for it that can only come from formal training or extensive experience using it, and as such I know that my first attempt to apply it (whenever that might be) will likely be a near-failure. That puts me off and I consequently choose to apply the not-inappropriate methodologys that I am familiar with, because I know their limitations/foibles well and feel more comfortable with them. This restricts my personal progress somewhat, but I know I'll get the job done proftably. Profitability often conflicts with personal furtherment, it seems, and that's a barrier to building the kind of confidence in a framework that can only come from repeated exposure and a minimum of experience.

Anyway, excellent blog Steve. It really makes me stop and think...

Thoric (CLA, CLED, CTD and LabVIEW Champion)

Active Participant

Profitability does make you conservative, but on the upside I think that may be a good thing. I think it keeps you honest!. Beginning to pull some ideas together for a presentation on this.

Active Participant

Might we see this presentation at an Architect Summit? 🙂

Thoric (CLA, CLED, CTD and LabVIEW Champion)