Human Language is Important, Even in Graphical Programming

[swatts]

I hope all you LabVIEW lovelies are doing good.

My brain is rested post-conference and hence I have things to write.

In know LabVIEW is a graphical design language but here's my theory on how the mind works with programming and design.

A well designed program reads like a story in your mind

Thinking back to olden times when I worked in a text-based languages the process would be as follows.

1. I convert the text into images for overall/complex interactions.
2. I convert back to human language for general understanding.

Graphical programming eliminates step 1 in that process, but I still need to convert back to human language to understand what is going on. As an example....

 

When "StopTiming" value changes to true add "Stop Counting" message to bottom of transition queue and set error if appropriate

This has been a theme for much of my thinking on design and can be seen in my writings here and many of my presentations.

This article is my attempt to put this into one cohesive theory.

Cohesion and Naming!

Talking of cohesion, language is a great indicator for a lack of it. Struggling to name your VI, State, Component, Class, Actor is a symptom of poor cohesion.

As a side note I'm becoming increasingly sceptical about abstract "management" Component, Classes or Actors, so anything with the Manager, controller or similar get some critical side-eye.

Another clue is to with connectives, especially logical connectives. These are ANDs and ORs, VIs, States, Components, Classes and Actors should not have any logical connectives.

At the block diagram level try labelling your Structures (While, For Loop etc), again clarity here should make it easy. Any difficulty is indicative of unclear thinking or lack of understanding.

Logic

Try to make logic positive and simple. Once again labelling the positive and negative cases is a great way to ascertain if your logic is too complex.

Positive logic is always easier to understand than negative, studies have shown that bugs like to live in complex and negative logic.

States

Recently I've applied more rigour to my state machine designs and it has been beneficial. See Transitions are Important! - State Machines Done Right

Transitions

See Transitions are Important! - State Machines Done Right

Messages, Responses

For asynchronous or distributed architectures think about the command and response. As an example in DQMH Fabiola stipulates the following.

• Request : Return Operation Mode (Imperative/Command)
• Broadcast : Operation Mode Needed (Past Tense)/Operation completed

Hit me up with some more examples

Lots of Love