Random Ramblings on LabVIEW Design

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

Re: Uncomfortable Truths

Active Participant

Hello my darlings,

Happy New Year!

I like to think of myself as a designer and not a programmer, I also think I'm a pretty good designer and on the journey to becoming a good designer I've learnt a few harsh truths. You can learn these hard way, or I may save you some frustration if you learn them here.

This article is about feedback and some of the conclusions you can arrive at from it.


If a user is consistently managing to break the flow of the User Interface (UI), entering "bad" data and making a system behave in unpredictable ways it might be tempting to say....

  1. They don't know what they are doing. 
  2. They need more training.
  3. It's deliberate sabotage.

The bitter truth is most likely that the UI design is poor. This can be solved by implementing gateways, wizard interfaces, state machines, or reading a book on UI design. While you're at it lose some ego, design pride is a cause for a great deal of angst. In these cases the customer is right 99% of the time.


If a system is difficult to change, maintain and update, some nice comfortable reasons may be.

  1. Software is hard.
  2. LabVIEW is bad at this kind of thing.
  3. Requirements are incomplete.
  4. Customer is unreasonable, demanding changes.

The most likely scenario though is that the software design is not as flexible as it should be. Some help can be found here.


This methodology/framework/technique is so great, it does all the things you need it to. You love it to the point of religious dogma, why isn't everyone using it?. Some easy reasons may be.

  1. People are stupid.
  2. You are a genius.
  3. People just need to spend time learning it.

One uncomfortable truth may be that your brand new 1970s design methodology/framework/technique is not as easy as you thought it was. I strongly believe that if something is difficult to explain then there is an inherent problem. Software design is difficult enough without adding complexity in the methods.

Another important consideration is that everything needs a Return on Investment (ROI). 

Does it

  1. Save me money.
  2. Make me money.
  3. Save me time.
  4. Make my life easier.
  5. Make things possible that weren't before.

This is from personal experience as we thought we had solved software with our LCOD methodology, it was infuriating to see people do it wrong. For me the trick is to enthusiastically share, but know that people are different. What's easy for me may be hard for you and vice versa.


Here endeth the January Self-Help section

Resolve to have more fun in 2019, it may be the last 2019 you'll ever see.



Active Participant

@swatts wrote:

everything needs a Return on Investment (ROI). 


I like that. I would add another, less obviously reasonable point:

6. Does it make me feel happy?

Joerg Hampel | CLA, LabVIEW Champion, DQMH Trusted Advisor | hampel-soft.com | alarchitects.org | gdevcon.com
Active Participant

Perhaps 1-5 lead to 6. I'm trying to think of an exception to prove the rule.

Active Participant

I wasn't sure if I should even post it, because I think I have a different kind of RIO in mind for that point. One that doesn't show up in a business plan. 


Quite often - maybe more often than is good for my business - I do things that make me happy, but they don't cater to any of your 5 points (some of them not software-related, of course). A CFO would maybe tell me to stop wasting precious time? But then again, that's why I run my own business :-)


On some days, doing whatever makes me happy is what keeps me from going insane...


All work and no play makes Joerg a dull boy

Joerg Hampel | CLA, LabVIEW Champion, DQMH Trusted Advisor | hampel-soft.com | alarchitects.org | gdevcon.com
Active Participant

Happy New Year Steve!


Excellent post, this would be an awesome poster... Maybe with funny cartoons!


I agree with Joerg, I will add to the ROI "does it make my work more enjoyable?". One of the best compliments we have gotten for DQMH is "it makes me smile when I use it". I should probably focus more on the ones that say that it saves them money or it helps them onboard people a lot faster, etc. All those are excellent comments and we are proud of those results as well. It is the smile though, that is the one that makes me smile and makes all of my work worth it!


Which lead us to the other point you made, no, I don't want everyone using our framework. We shared it for free and we hope it helps a lot of people but we know that it is not for everyone and we cannot please everyone. There is so much more for us to learn! Thanks for the reminder that we do need to keep humble and remind ourselves that we are no geniuses.


To your first point, one "comfortable" answer I hear people giving to end users not using their product correctly is that the end user doesn't read the manual. I believe there is even a not so nice acronym "RTFM" for that. Well, if they have to read the manual to be successful, maybe we didn't design the UI as friendly and intuitive as we thought we did. Let's get back to drawing board and improve it. This does not mean to not write manuals, it just means not to blame people on not reading the manual. It is OK to expect people to read the manual for obscure or not frequently used tools.


Thanks again for sharing your wisdom with us.




Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant

RTFM! Hah! how many jobs in mil/aero have I done that the cure for an obscure process is to add pages to the manual. Rather than make the process easier or more intuitive.



4. Read The Fluffing Manual, add to the fluffing manual, moan at users for not using the fluffing manual. 


I thought I'd turn on my airline overdub on to make it safe for work. If you fly NorwegianAir check out Three Billboards Outside Ebbing, Missouri. It's fluffing hilarious.

Knight of NI

RTFM = Read The FANTASTIC Manual!


Not much to add to this article.  Just remember that we always have room to improve.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Active Participant

For me the biggest barrier too improvement was design ego. Difficult to lose, refocusing away from my pride in the solution and onto pride in customer relations was my key.

Proven Zealot



Interesting comparison between "Ego" and eastern "Zen" religions.


Do we need to start trying to become enlightened programmers?

Active Participant

I have an article about that Smiley Very Happy


Proven Zealot

@Steve, I should have known. Heart


I sometimes find that the ego gets a bad rap.


Borrowing from Freud's definitions, I believe getting your Id in order is the key to making the ego obsolete.  By aligning your Id with your environment and conscious mind, you remove barriers within your own mind and clarity ensues. Everything else is repression and willful control (Freud would have a field day with regard to repression - "how dou you feel about your mother?" Smiley Very Happy). Don't ever forget, willpower is a limited resource.


This is quite possibly the root cause for my interest in neuroscience, endocrinology and epigenetics.  All of these play a role in forming and continually molding your behaviour (internal and external).  One more shameless plug for "Behave" by Robert Sapolsky.