Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 
swatts
8436 Views
12 Comments

We're funny creatures us programmers, I suspect LabVIEW programmers might be a strange subset of a strange breed.

In the years I've been in the industry I have come up against some interesting characters, hired some and fired some. So in the style of a wildlife documentary here's some of the stereotypes I've spotted. Starting off with the most deadly examples.

The Crooks

The Fake - Fred Brookes says that a poor programmer will be 10x slower or more than a good programmer. I would go further, I have seen projects go backwards and fail because of poor programmers. I would suggest also that the ease of entry to the world of LabVIEW allows people to appear a whole lot more competent than they really are.

The Owner - Any programmer who hides their code should be sacked, it's as simple as that.

The More the Better - Paying Programmers by the hour has some disadvantages, one of which is they tend to work to the time and not the problem. I had a system to support about 15 years ago written by an hourly paid contractor, about 50% of the code was checking all the hard-drives to make sure they were the correct ones, which begged the question how the hell would it have worked without them!.

THESE ARE DANGEROUS AND SHOULD BE ESCORTED FROM THE BUILDING

The WTFWereYouThinkings

This family of lazyass ugly non-designers are my pet hate!! They are named after an Irish fella at an NI-Days who was showing off his code, the Front Panel was a brown background with a green array falling out of the bottom of the screen. It was OK tho' because the screen had a scrollbar on it! Anyways I politely asked what the application was being mild mannered and pleasant, my friend from another Alliance Member company came over and declared loudly "WTF WERE YOU THINKING!!!". How we laughed.

The Blunderbuss  - No need to use the mouse, just load up your Blunderbuss with VIs and fire them across the room. Commonly heard saying things like "Oh I'm too busy to tidy it up"

PrairyProgrammer - Even more baffling is when I open a block diagram and all I see is white white and more white. So called for their love of wide open spaces. Makes my RSI hurt just thinking about it.

IMAXProgrammer - Hierarchy is for wimps! real programmers have one huge diagram, obviously can only really be appreciated in an IMAX cinema. (c) Mad Bob McMad

Crammer - The enemy of the PrairyProgrammer can fit the IMAXProgrammers block diagram on the back of an atom.

If it is not their first program (we all should be forgiven our first program), ESCORT THEM FROM THE BUILDING, call me I'll do it for you.

The Geeks

The Syntax Jockey - Enthusiastically embrace every new tool, whether or not the problem needs it. Will fly through the CLA and CLD exams as they have remembered every last strange little issue in functions no-one has ever used.

The Genius - If you're a genius every day you're doing the wrong job, code written by The Genius is usually indecipherable to mere mortals, sometimes The Genius comes out in normal people and they write some spectacularly clever code. When your brain comes down from genius levels throw this code away, you won't regret it.

THESE CAN BE DANGEROUS, MILD PRODDING WITH A POINTY STICK SHOULD BRING THEM BACK IN LINE.

The Timewasters

The soapbox kid - C++ is the only language, if you don't program in that you are goats droppings, no! no! no! LabVIEW is the future lets post a discussion on the forum and thrash out the merits of each....Nah let's not. You don't hear mechanics arguing about which is best a wrench or a hammer, they are just tools. It's really not something to get political or religious about. The best argument is to write nice, robust and maintainable code quickly.

The not invented here - Sometimes as a contractor you will be put in a hostile environment, the instigator of this hostility is usually crusty, old and a bit fearful. They will hate anything you do. All you can do is deliver good code, eventually you may earn grudging disdain. Beware if they are the signatory for your project.

THESE CAN WASTE A LOT OF TIME ON A PROJECT, TIME TO REACH FOR THE POINTY STICK.

The Project Managers Nightmare

The Optimist - Do you factor in all the things that regularly get underestimated when you are costing/scheduling a project. Here's some things that can be missed.... Documentation, Testing, Hardware that doesn't work as expected, customers who can't communicate requirements, Reporting, Error Handling, late changes. Symptoms are late delivery, poverty, unhappy customers, missed deadlines, stress.

The Puppy - The Puppy is eager to please, this is not a bad thing it just needs to be managed. I'm going to be controversial here...the customer is not always right. As the designer it is up to you to guide them in the right direction and not pander to their every whim. Sometimes they will ask for something that will weaken the design, resist or at least make it eally expensive. Cost is usually a good test of how much it is required.

THESE ARE COMMON AND NOT ENTIRELY BAD TRAITS, IDENTIFY AND MANAGE.

As well as being an amusing exercise, it is interesting to note the traits that apply to ourselves.

So what are you?

Love Steve

PS At first I was a Syntax Jockey, now I think I am an Optimist and a Puppy. Some would say I was A Soapbox kid. Only ever been a Genius once.

http://www.aaronstannard.com/post/2013/12/19/The-Taxonomy-of-Terrible-Programmers.aspx

“The best programmers are not marginally better than merely good ones. They are an order of magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design or problem-solving ability.”
—Randall E. Stross

swatts
3975 Views
5 Comments

One of the traps graphical programming can spring is that sometimes the elegant and fun interface can lead you into bad design decisions.

A common one for me is tinkering with logical decisions until I end up with something like this...

ComplexLogic.PNG

I sometimes view the block diagram as a conversation between you and another developer (and as Fabiola De la Cueva asserts, it's good to think of this developer as a psycopath who knows where you live). Now the conversation for this bit of code goes something like.

IF (OpenCCT Detected NOR SOC Detected)

AND

((Keyswitch=Remote AND Source NOT=RT Localhost)

OR

((Keyswitch=Local AND Source=RT Localhost))

OR

(OP Power Setpoint=0)) THEN do something..

I can envisage Fabs psycopathic developer reaching for his axe sharpener.

So what are the alternatives when complex decisions are required?

I personally prefer words and nested case statements using enumerated types.

LessComplex.PNG

It's more readable and less likely therefore to have errors. These 2 statements are related!

Some people prefer look-up tables, decision matrices etc etc. I suggest these should be implented using a single VI with all the inputs brought in. A test-stub can the be used to exercise all the combinations. The output to this VI should be an enumerated type describing the decision made.

Code Smell#3: Complex Logic  

Code Deodorant: A Case should be described by one simple sentence that can have 1 AND or 1 OR in it. Where possible use words rather than boolean or Maths to make your decisions.

The other thing that commonly causes issues in code is negative logic.

The human brain is a positive thing generally, negative logic causes problems in understanding and therefore bugs.

Code Smell#4: Negative Logic  

Code Deodorant: Right-click on the case statement, bring up label, and write the logical description for the TRUE case. This simple thing has saved me hours of head-scratching and improved my handling of decision making.

Also avoid NOTs etc where possible.

Lots of Love

Steve

ooh pithy quote....

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

— Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.

swatts
4236 Views
2 Comments

“Examinations of typical programming projects will show that, over the duration of the project, programmers spend over 50% of their working hours looking for and correcting their mistakes. The usual 'solution' for this is remarkable.....

We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process”

Glenford J Myers 1978

I've had the good fortune to look at  lots of software in a variety of languages in my career and it is endlessly fascinating, and when I talk about design to some perpetrators of bad code a common response is that oh! design is not black and white, there is a grey area. This got me thinking.....

Design.PNG

In quite an angry moment I drew up this representation of what I have experienced, I think design is various shades of brown, a small grey area and an even smaller white area. The brown area is various shades of awful.

The time graph can also be viewed as a cost graph and it is the cost throughout the lifecycle of the application. Disclaimer:This is based on my experience and not research.

So looking at a brown project.......

It's a classic code and fix job, tight coupling makes the code brittle, inflexible and hard to change. Lack of cohesive modules and poor abstraction makes the code hard to understand. So 95% of the project time is used up and 95% of the code is written. The last 5% of code will not take 5% sadly, you'll be adding functionality to code that will be resisting you. Bugs are hard and expensive to find, tight coupling means changes made will ripple outwards causing unpredictable results in related modules. Simply put, it takes a lot of time, effort and cost.

Compare with a grey project.......

It's had a bit of modular design applied to it, this design work gives the architecture flexibility. Changes can be made simply and easily at the end, when most customer input is usually given. The design work makes the code easy to understand, therefore bugs are easier to detect. Loose coupling ensures that changes and additions to a particular module does affect other modules.

But what about Exceptional?

One of the challenges for a designer is knowing when to stop.

So are you a designer or a syntax jockey?

A designer will be spending their time thinking about the problem that they need to solve, a syntax jockey is likely to be thinking about what new tool or technique they can apply.

Software Facts of Life

As grown-ups I think we can face the truth.

  • Software is complex
  • Software is not malleable
  • Software will have bugs
  • Software will not be fully defined until delivered

Badly designed software exacerbates these problems.