Random Ramblings on LabVIEW Design

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

Steve

WillyShakespeare wrote: He that a fool doth very wisely hit Doth very foolishly, although he smart, Not to seem senseless of the bob: if not, The wise man's folly is anatomized Even by the squandering glances of the fool. Invest me in my motley; give me leave To speak my mind, and I will through and through Cleanse the foul body of the infected world, If they will patiently receive my medicine.

When we started out writing "A Software Engineering Approach to LabVIEW" we wanted to base it on a financial book called the Motley Fool, (I was going to link to it but it appears that it has become the very thing it was fighting against). The purpose of the book was to debunk the artificial complexity involved in finance in a sharp and humorous manner. Top-tip writing light-hearted is hard work!

Now the great thing about being a Fool is that you can say things and to hell with the consequences. Inhibitions to foolishness come in the following forms

• Insecurity
• Personal connections
• Corporate/Business
• Cultural

Looking at each in turn...

Insecurity

I have only ever been to university to write software, my education was primarily writing software and fixing machines in factories. So in a room full of qualified engineers, Champions, CLAs etc etc I sometimes feel out of my depth. Generally this exhibits itself in lack of participation. Luckily my big mouth and tiny attention span help over-ride this. I wonder how many project blunders could have been avoided without these inhibitions.

Personal Connections

The classic here is when a client becomes a friend, said client then gets into problems with a project. Strictly speaking you should speak out for the good of the project, but this would get them into trouble. This is quite close to my heart. I think the nature of LabVIEW is that we are always at the pointy end of a job, bad design decisions will be exposed at this time.

Corporate/Business

We get a fair bit of work from our industry relationships, this work is marvelous for us as we don't like selling, so any jobs that come to us are most appreciated. There is therefore a pressure to censor some of the things that pop into our heads. This is actually less of a problem than you would imagine, because it is in everyone's interests to have a successful job we tend to all pull in similar directions.

Cultural

These pressures are very hard to overcome but they all have the affect of restricting free participation (the heart of foolishness IMO).

Age - We're mostly brought up to respect our elders, all well and good. But because you're older then me doesn't make you right!

Seniority - Your wage packet dictates a certain amount of care when dealing with management. But because you senior in the company doesn't make you right!

Gender - I shouldn't need to, but I guess I have to. Because you are Male/Female/Transgender doesn't make you right!

Education - Because you are from (insert school here) doesn't make you right!

Race - Hopefully this is obvious but because you are (insert pigmentation of skin here) doesn't make you right!

Technical - Because you have Linux at home and think in COBOL doesn't make you right!

Customer - Sometimes the customer is right, sometimes not! I wonder how many projects have failed because "the customer is always right!"

One of the greatest causes of stress in our business is when a difficult project goes bad, one of the worst things you can do in those circumstances is to sit on it. From a project managers point of view having feedback early is extremely valuable. This is one of the hardest things to do in our business.

One of the best things about writing a blog is the feedback, discussion and argument that follows. I've learnt a great deal from this interaction so keep it coming and don't inhibit your inner Fool!.

Lots of Love

Steve

To Be Honest.... - Liz Keogh <-- a really nice presentation on this very subject.