Random Ramblings on LabVIEW Design

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

Software Design and Italian Cooking

Active Participant

Wotcha Software Chefs

Hope everyone had a stress free holiday.

In the last article we discussed accounting and how that analogy applies to the software process, this article came together after watching a documentary about the game Half-life.

 

Spaghetti Code (Unstructured)

This is likely a term you have come across with regards to poor LabVIEW structure, in fact it was a common term in software design well before LabVIEW made it graphically come to life. The image below is from our book and I made it in 2001.

Figure 3_5.pngImage 3.5 Software Engineering Approach to LabVIEW

I think it works really well with the dataflow as the spaghetti and the functions (VIs) as the meatballs.

 

It is not so descriptive of layer based designed, something that OOP has a lot of.

 

Lasagna Code (Layered Monolith)

 

Layers are NOT a bad thing, but they can be frustrating when they get in the way of navigating to the Region Of Interest in your code. ROI in code is something I'm trying to enumerate better, for now think of it as the area(s) you are focusing on during your work-flow. In LabVIEW (and other languages) you have to wade through several layers before you find the actual area you are interested in. I find this interrupts my thought processes.

 

So the answer to this may be 

 

Ravioli Code (Microservices/Actors/Asynch Processes)

Here we have a number of small loosely coupled software components, acting as independently as possible to achieve the final solution. The downside is that sometimes the complexity can be pushed into the inter-communications between the components.

Another danger is that the software components are too small in their duties and the intercommunication complexity takes over. Or the software components spawn new software components in complex ways.

 

You are then in danger of producing....

 

Risotto Code (Lots of Very Little Software Components Interacting together)

Remember that complexity does not disappear, it gets reorganised and moved about. By taking from the functional side of things, it may pop up in the sauce, so you end up with dumb components in a complex framework. Or difficult to understand communications. Sometimes it's beneficial to sacrifice individual component simplicity for a better understanding of the problem solution.

 

Anyway all Italian food is great, so cook up some nice code in 2019 peeps

con molto affetto

Steve