Random Ramblings on LabVIEW Design

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

LabVIEW is Easy/Optional A Closer Look

Active Participant

Hello my algorithm creating chums,

I took the opportunity to vent my spleen in my last article, I suppose I had better explain myself.

I'll attempt here to codify my proof that LabVIEW is not easy and programming cannot be optional in the vast majority of cases.

I've shown this graph in a couple of presentations.

Complications.png

It's by one of the greats of programming Alan Kay in his presentation that can be found here.

 

And the point I have tried to make is that you use software to solve a problem and that problem has inherent complexity, we use a software language (and other things like documents) to describe the solution to that problem and this adds complications. So a solution to a problem will always be more complex than the problem. How much more is a measure of both the language that is used and the design applied. Note: this is not a precise equation, rather an illustration to be used in an argument.

 

As we add humans to the mix the complications begin to add up.

 

So a fairly accurate rewrite of "LabVIEW is Easy" might be.

With the correct design choices LabVIEW will not make an easy problem a lot more difficult to solve.

 

I don't see marketing going for that one and I would never be so presumptious as to say marketing was easy!

 

So why do I take umbrage with the "Programming Optional" message.

 

I've seen this message applied to various configuration based systems before and they work well enough within their limited scope. Step outside the scope and you are left with a black box that you cannot modify (or do not have the understanding to modify). I've never had a job where we haven't stepped outside the scope, never ever.

 

"Oh it's 99% there........but we need it to do this one extra thing"

And you look a bit stupid if you say you cannot supply this one extra thing. This has happened pretty much every time I use a blackbox solution. I now insist that being able to tinker with the insides is a design decision for SSDC projects

 

My final word on this is an economic argument, if I only wanted to do simple things in a language why would I spend so much time and money on that language. The inference is that I will always need to do something more complex.

 

I love the discussion of Complexity vs Complicated and at the heart of this is the path to self-awareness. To increase my codes complexity and to make it less complicated is the thing that drives me on.

 

In the next article I will go through the SSDC code review checklist. I promise it's going to be a thrill-ride!

Lots of Love

Steve