Demo: DQMH as a "brat" VI

[FabiolaDelaCueva]

The main issue here is differentiating between: 

• Sample code
• Reusable code

For sample code, I care about the other developer understanding how the VI is done and understand some underlying principles. 

Reusable code, it could be password protected and the other developer doesn't need to care about how it is implemented. What the other developers care about is that it is "bullet proof" and it has been tested. If I am going to reuse this code in multiple projects, I want to make sure that it has been tested and that it does not add problems to my code, such as the ones mentioned above.

If we build either Darren's or David's solutions to a reusable package, then the palette in both cases has a single VI in it. When the developer wants to add this functionality to a VI, all they have to do is grab their Ctrl+A reusable VI from their palettes (or via Quick Drop!) and put it in their code and it works.

Another advantage about bullet proof code that if it is shared via packages is that I can start using David's implementation, then decide that for the next revision I will use Darren's and finally deciding to use James' solution. Every time it would be transparent to the developer reusing the code, all they care about is that Ctrl+A works.

Looking for simple VIs in reusable code leads to tons of technical debt. I have seen it over and over and over again. Like James said, you want your reusable code to not be dealing with things that you have already figured out. I have seen developers reducing the QMH project template to a simple Producer Consumer full of naked calls to Queue functions, only to find later on that the reason they were wrapped in subVIs was because corner cases were being addressed. 

So the question would be, do you want sample code or reusable code? If you want reusable code, why do you care about how it is implemented?

[drjdpowell]

---

@FabiolaDelaCueva wrote:

If you want reusable code, why do you care about how it is implemented?

---

Unfortunately, one would be (rightly) reluctant to add an entire framework just to access one minor function.  Especially if you are unsure of whether there might be problems with it that you might have to debug.  Frameworks have a significant learning curve, and you  don’t necessarily want to have to make an investment in more than one.  

[FabiolaDelaCueva]

---

@drjdpowell wrote:

---

@FabiolaDelaCueva wrote:

If you want reusable code, why do you care about how it is implemented?

---

Unfortunately, one would be (rightly) reluctant to add an entire framework just to access one minor function.  Especially if you are unsure of whether there might be problems with it that you might have to debug.  Frameworks have a significant learning curve, and you  don’t necessarily want to have to make an investment in more than one.  

---

If the single VI that provides the small functionality is password protected, there is no need to understand the underlying framework. This framework could be Messenger, Actor Framework  or DQMH. In the case of DQMH, the only dependency is to the Delacor DQMH library in vi.lib. 

[David_L]

Just to close the loop on my end, I had an off-line discussion with Fabiola and she was successful in convincing me that using a tried-and-true architecture for this use-case in fact makes more sense than the "Simple" one-VI solution.  To be clear, I'm not specifically making a case for DQMH, but reusable architectures in general (Actor Framework, Messenger, JKI State Machine Objects, DQMH, etc).  However I did learn more about DQMH and there's definitely some cool stuff going on in there.

Here's a summary:

• For re-use code that are simple functions with inputs and outputs (such as the OpenG style bag of VIs), we agreed that one of these architecture is probably overkill.  However there are definitively cases here where it might be handy, especially if you intend on augmenting or extending the functions with additional similar functions or plug-ins
• For any code that is spawning a parallel process to go off and take care of some tasks asynchronously, a good architecture is a must to correctly start and stop the async code, protect the data from other processes that might try to break into your data communication channel, etc.  
• With my specific example, I was blurring the line between the above two use-cases.  In my head the ctrl-a functionality started as a simple little re-use VI that could enable Ctrl-A on a string, but in reality to accomplish this I needed to create a process which moved it into the second bullet zone.
• My concern about having to teach new people the architecture may not be as valid if using proper modularization practices.  Realistically, I would make this re-usable thing completely uncoupled from the rest of my code.  Once I know it works as intended, I'd lock it up, package it up and then seal it away it it's own Source Code Control.  The main application would be a client of this sub-thing and should never really need to dig into the guts of it.  If there's something wrong with the module, I (or the future owner of this tool) would go back to the SCC, edit it separately outside of the main app, rebuild a new package and then pull it in from the main app.  
• Using an architecture (especially DQMH) offers all sorts of other advantages for debugging and troubleshooting the code.  I'll let someone more familiar with these tools elaborate if they want, but I can see where I'd want to at least have them available in case something quirky starts happening.

Anyway, thanks to all for the healthy conversation.  Obviously this little tool is a very non-critical thing, but the overall concept and discussion was a good lesson in proper programming practices for me.

Happy Wednesday,
David