Random Ramblings on LabVIEW Design

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

Re: Project Biased Design vs API/Tool Biased Design

Active Participant

Hello My Graphical Programming Gurus,

Had a jolly, but exhausting time at GDevCon#1 and it felt like we pulled it off! but I get a positively biased view because I'm huge, loud and scary looking. Allow me to thank the GDevCon team, truly humbled to have them behind the idea.

04_144806.JPGGDevCon Team

Also our amazing presenters, sponsors and the venue, they were all essential to an excellent new event. Vids and Piccies coming soon!

 

This article attempts to clarify a position I've increasingly taken and that is ..

 

There are 2 types of LabVIEW programmers.

 

API/Toolkit Programmers

and

Project Programmers

 

These programmers have very different design perspectives. First lets look at what makes a good API.

 

After a bit of research an API needs to be ...

 

Scaleable, Extensible, Reusable, Robust, Modular.

 

We've discussed SMORES and I've pushed back on it a bit, saying that some of this wasn't that applicable to me. 

 

At SSDC we don't do APIs/Tool-kits or reusable libraries we do projects, whereas within NI I think the majority of LabVIEW written needs to follow these rules. The vast majority of the training on LabVIEW comes from within NI and I think from a design perspective this means that the rules for good software design are therefore biased towards tool-kits.

 

So what is important for people who design projects, well here's my list....

Debuggability - I want to use every tool in LabVIEW to help me fault find.

Flexibility - I want to rapidly modify and rebuild my code, because these modifications usually happy at my customers site, when time is a rare commodity.

Readability - My solution to the problem has to bear a good relationship to the problem. I should be able to read this solution in the block diagram.

Configurable - I want to be able to change my application, without changing the source-code.

Efficiency - I don't want my computer (or my customers) to struggle to run my code

 

Many of the design traits required for APIs are really unimportant at the project level. So picking on re-use for example : it's one of the first things I sacrifice if it affects any of my primary requirements.

 

Oh and I think frameworks have another set of requirements too!

 

In short I think we need to consider what we're being taught and the perspective of the people teaching it. This might also be some sound life advice, you can have that for free.

Lots of Love

Steve

 

Comments
Member

I would even say that both types of LabVIEW programmers cater to different business models.

 

Sometimes, I'd love to be able to work on a single project for 3 years and put all my love and energy into it, hone it and fine-tune it. But in reality, projects often take less than 3 months, and there is barely time to get the required features implemented. 

 

As a small company of few people, and working with small teams, we often have a hard time coming up with the resources to maintain and grow our own libraries and templates and helper VIs etc. But I do like to work on familiar code, and I'm totally convinced that it helps us to deliver better software in less time.

 

So my question is (and we had this discussion recently regarding the definition of the term "framework"): Where to draw the line between a piece of code that should be reusable as a template or project basis, and code that is project-specific?


Joerg Hampel, CLA & LabVIEW Champion | hampel-soft.com
Knight of NI

To add to Joerg, getting other people in the company to adapt a reuse library is also difficult.

 

But just thinking through my projects, I have found that an API will usually help my over-all project.  Usually this is due to modularizing the problem into smaller "actors" (usually QMHs).  But creating a message API for these actors has really helped when digging into the interesting logic of the top level state machine.

 

Once last thought: It also depends on your company goals.  I find that many Alliance Partners see a lot of different types of projects, so it makes little sense to concentrate of reuse.  But for test engineers like myself at a specific company who will see many projects that are mostly the same, it makes more sense for me to concentrate on reuse and dynamic architectures.  And for full disclosure, I have been on both sides of that coin over the last 5 years or so.


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

@Joerg I agree, we're now working on larger projects over periods of years and the support and upgrade model is much more prevalent. This is very different to work we were doing 5 years ago. So we're spending much more time on an existing code-base rather than many new projects.

In answer to your question: you do the best the budget allows and what the ROI (Return On Investment) pays. So there are generic parts of an application and process that will be common to projects. For us hardware is not one of them really, whereas we get a lot of benefit from re-using Config, Calibration, UI, State Machines, documentation, project structure.

@Tim your one last thought nails the point I'm trying to make I think. I'd like people to think about their own use-case and what is important to them and design accordingly. That way we would have less discussions along the lines of - 

"x and x is the best way to do something...." and get more -

"x and x is the best way to do something because in this case we're doing y and y"

Active Participant

I'm both those types of programer, but generally at clearly distinct times.  I long ago abandoned having a "reuse library" that is a grab bag of useful functions.

Active Participant

That's really interesting James...

Riddle me this then, why is managed re-use such a focus for computer science and yet some of us experienced LabVIEW programmers neglect it so. I have theories, but always assumed it was mostly my bias towards project based programming.

 

As I've had to explain a fair few times, we're not against re-use, we just don't invest time in the managed re-use as we're supposed and I know full well James re-uses frameworks as we do.

 

My current theory is (speed/effort of creation) vs (speed/effort of archival and retrieval) being different in LabVIEW. Or maybe it's just more fun being a programmer than it is being a librarian.

Active Participant

I'm not sure what "managed re-use" is.  My reusable packages (JSONtext, SQLite, Messenger) are highly reusable, and there is a clear division between that and some project code that I might want to use again.  There is a higher level of effort needed to make a complete reusable thing, and that requires high payback.  You have to know that you will use this again, and having a polished tool will make writing project code better on multiple projects.

Member

@swatts wrote:

As I've had to explain a fair few times, we're not against re-use, we just don't invest time in the managed re-use as we're supposed and I know full well James re-uses frameworks as we do.

 

My current theory is (speed/effort of creation) vs (speed/effort of archival and retrieval) being different in LabVIEW. Or maybe it's just more fun being a programmer than it is being a librarian.


Whenever I discuss reuse with teams of developers/team managers at (larger) organizations I get a number of reactions. First; That sounds like a lot of work and it isn't on anyone's career path to manage a reuse library. Second; It sounds wonderful and we really need a way to reuse code, but we simply don't have the bandwidth. Third; developers are working on very different projects, or in isolation (silos?), and don't share code (and ideas). Those reactions could be evidence that your current theory is correct, Steve. 

David Corney

Certified Developer, Certified Professional Instructor and LabVIEW Champion.
Active Participant

@swatts wrote:

 


Riddle me this then, why is managed re-use such a focus for computer science and yet some of us experienced LabVIEW programmers neglect it so. I have theories, but always assumed it was mostly my bias towards project based programming.

 


Maybe it's the simple economics. Let's talk about team sizes and their goals. What's the biggest LabVIEW software team you know? The highest number I've heard of is about 70-100 (and this probably wasn't just a single team, but a few teams working towards different goals). But most of the teams are much smaller. On the other hand there are teams of hundreds or thousands of developers working on a single product, and we're not even talking about Silicon Valley. Sometimes those products require that you'd implement new feature to production in few hours. Without reuse, such products development would have two major points of waste:

  • Hundreds of developers making the same piece of code which takes 1 hour to make. Something like 300 x 1 hour = 300 hours = $$$$$ burned without adding real value. And now let's think about a task which takes weeks to complete.
  • Time for developing something that we could reuse = we're late with the feature = customers didn't get the feature in time = $$$$$ not earned. I'm not exaggerating with those few-hours dev cycles, this is typical for any sales services, fintech, martech, or any other XXXtech.

We're talking about the scale of millions of dollars, that's why reuse is so crucial in today's IT world. In fact it's now going further and further from just a simple code reuse. People reuse code, infrastructure, services, they have scalable clouds where they could set up 1000 high performance servers with a simple config file, which is in stored in their repository, because they implemented "everything as a code" policy.

That's the big picture. Going back to our (relatively small) LabVIEW world:


@swatts wrote:

My current theory is (speed/effort of creation) vs (speed/effort of archival and retrieval) being different in LabVIEW. Or maybe it's just more fun being a programmer than it is being a librarian.


That may be also true, and I'm assuming that LabVIEW might be worse for reuse than "others". But in the context of what I've wrote above: there might be no actual reason to make it much better, because the scale of the projects in LabVIEW is different. We might have a need to implement a quick fix in our test&measurement system in just a few hours, but LabVIEW is mostly good at that without any reuse. In the same time someone somewhere is setting up large service for tens of thousands of customers per hour, with large database, scalable backend and connectivity to other existing internal and external services, and he wouldn't ever be able to do that by simply "opening the block diagram and fiddling with the source code". In this case reuse is crucial.

That doesn't mean we don't benefit from reuse in LabVIEW - we do. But reuse might not really be needed for succesfull business in LabVIEW, and we all see many examples of that. Of course there are also all shades of gray between "no reuse needed at all" and "everything reused because otherwise our business will fail", but in my opinion typical LabVIEW development is closer to the first one. That being said by a guy who actually like to reuse things Smiley Wink

Active Participant

Great comment PiDi, once again beating the article!

I like re-using things too and re-use a great deal. What I don't tend to do any more is manage my own library of re-usable components.

There's a great deal of nuance and use-case in your comment and that is precisely what I would like to see in teaching and presentations about architectures, design and process.

So managed re-use is an economic consideration, designing an architecture with re-use in mind is a zero sum game (the trade-off being complexity, readability, understanding), a process focused on re-use is really dependent on the type of work being done and the type of team doing it.