Lean LabVIEW

[swatts]

This article pulls together some strands discussed here into one presentation that I gave at DevDays Galway. It describes how SSDC can produce large projects without running into some of the issues that are seemingly prevalent in the community. Our stuff edits fine, builds fast and is easy to manage. Lots of time and effort has gone into making this the case. 

1. A Tidy Project is a Happy Project
2. Cross Linking
3. Project Portability
4. View Dependencies with suspicion
5. Polymorphism – Bloat Alert
6. Immediacy – Glue Vs Do
7. Lean, Clean Code
8. Lean Error Handling

I wanted to emphasise that some of these techniques are old and that adds worth to them, a technique that has stood the test of time is way more useful than some new method or tool that we're currently interested in. It was quite a fun slide to do too.

1. A Tidy Project is a Happy Project

Link to article here

2. Cross Linking

Vic Stennings Principles of Project Hygiene (1979) - Principle 5
"Changes should be controlled, visible and of known scope"

The enemy for predictable software is silent changes

Editable VIs that are part of the environment and not part of the project (and not under SCC) are out of control.

Take for example the FTP library in LabVIEW, it's missing some useful functionality. Namely I want to display the how big a file is and how much has been transferred. So SSDC take the FTP library out of VI Lib and embed it into our projects.

This means we can load our projects onto any computer (from our repository) and it will function as expected.

To ram the point home I display where VIs can be freely edited in the environment.

3. Project Portability

This is pretty much written up here and here

4. View Dependencies with suspicion

In this section I discuss the type of programming where the programmer constantly reaches for the re-use sweety jar. The downside for this is bloat, dependencies and knowing a library over understanding a tool.

“It can be better to copy a little code than to pull in a big library for one function. Dependency hygiene trumps code reuse.”
Rob Pike

5. Polymorphism – Bloat Alert

One key area of bloat comes from using polymorphism as you are supposed to! I apologise for using the OpenG stuff in my examples here. I'm not against libraries, it's more about the unconstrained reaching for them and the implications they have on the code-base. Better dependency handling would make this less of an issue.

So here the polymorphic VI is filling up my hierarchy, but actually when it's in the project and working I don't think it needs to be polymorphic any more. Brutal I know, but I use the hierarchy display and don't like clutter.

Extensible: "but suppose if someone wants to add X here tomorrow". Be wary unless tomorrow is a real date, and someone is a real person.....

6. Immediacy – Glue Vs Do

This section just summarises and clarifies my ideas described here

7. Lean, Clean Code

This section talks about putting effort into making your block diagrams pretty and minimal. The only info on the block diagram should be that required to describe the solution to a problem.

Here I use the QMH example to demonstrate stuff that can be removed from the block diagram (and stuff we remove).

Next I discuss comments and a lean approach to them. kicking off with this pithy quote

"A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly in comments. "
K Henney

A) Bookmarks are great, we use them for quick #TODO notices, tracking issue numbers and traceability for large changes.
B) Set LabVIEW to display constant label names, it improves the readability of the code at little cost.
C) I like the blue template comments that indicate bits of the template that can be modified. In this case adding new messages to be handled by the UDP receive loop.
D) Labelling case statement logic, improves readability and as a bonus improves logical design. This is because if you have to write the logic down, it becomes very clear if it is becoming complex.
E) We Number and label our loops, this is good for telephone support to guide people to the correct structure and similar to D) labelling your loops clarifies your design decisions.
F) Shift registers benefit from being labelled

G) Polymorphic selectors make good message sending mechanisms

H) Label your For Loop with an iteration description

Finally I talk about Lean Error Handling

Here I show how it's actually more interesting to error trap the event, state, comms message, UI message rather than the VI.

I'm debating whether this will be my last presentation, I think perhaps I've said enough.

Lots of Love

Steve