When to use DQMH?

[FlatCat]

The documentation mentions "medium- to large-scale projects". But what defines these?

I see the beauty and utility of DQMH, but my question is whether to start adapting a set of existing applications to use it. I work alone, (although someone might eventually need to take everything over). The applications are fairly straightforward, with about 100 vi's in a data collection loop, a UI loop, and a data saving loop. These usually communicate via queues, and some User Events that I set up by hand. At what point does it make sense to update an existing and fairly stable application to DQMH (other than the fun and the challenge of it)?

[joerg.hampel]

Hey Flatcat,

thanks for looking into DQMH. Your question is a great one, and I rarely see it being asked, so thanks for that, too!

---

@FlatCat wrote:

The documentation mentions "medium- to large-scale projects". But what defines these?

---

I think this comes from the fact that "small-scale projects" usually do not have the need for modules running in parallel - which is the first and foremost feature of DQMH: Modularity. But reducing DQMH to that single aspect doesn't do it justice. 

At HSE, we don't really make that distinction, size-wise. All our applications are based on DQMH. Even some of our reuse libraries facilitate DQMH modules. You get the QMH pattern for free (so no manual creation of loops or queues or events), together with scripting for adding your required functions, and on top, you get the API tester which helps with making sure your code works as expected on its own. 

Here's more on why we love DQMH.

---

@FlatCat wrote:

At what point does it make sense to update an existing and fairly stable application to DQMH (other than the fun and the challenge of it)?

---

The only reason I can think of is sharing/reusing code between your applications. If you want to do that, you will need some level of modularity - i.e. the code you want to share should be separate from the rest of your application, not depending on it, and ideally have a proper API defining how it should be integrated into your applications.

So when you have to add a feature to an application and that feature is (or might be) needed in other of your applications, too, that might warrant refactoring your application and carving out said functionality into a DQMH module.

Be aware that you don't have to migrate your whole application to DQMH. You can totally start with a single module, and see how it goes.

[FlatCat]

That''s very helpful, Joerg, and not something that I see explained in the various documents and videos I have watched so far. Thanks very much.

[drjdpowell]

I note that "Modularity" can be thought of as dividing up a complex large-scale project into a series of simpler small-scale projects.  Thus any good modularization framework should be based on a good small-scale template that should be usable by itself for a small-scale project.  It might seem "overkill" in a way to use a modular framework with only one module, but there are advantages (such as when project requirements unexpectedly grow and the project isn't so small-scale anymore).

[Ozfarmboy]

---

@drjdpowell wrote:

I note that "Modularity" can be thought of as dividing up a complex large-scale project into a series of simpler small-scale projects.  Thus any good modularization framework should be based on a good small-scale template that should be usable by itself for a small-scale project.  It might seem "overkill" in a way to use a modular framework with only one module, but there are advantages (such as when project requirements unexpectedly grow and the project isn't so small-scale anymore).

---

Agreed.  Not many projects start out small and stay that way.  Most in my experience grow and in ways you don't expect!!

[joerg.hampel]

---

@FlatCat wrote:

The documentation mentions "medium- to large-scale projects". 

---

Hey FlatCat, we're looking into updating our documentation. Can you point me at where you read this sentence?

[joerg.hampel]

---

@drjdpowell wrote:

I note that "Modularity" can be thought of as dividing up a complex large-scale project into a series of simpler small-scale projects.  Thus any good modularization framework should be based on a good small-scale template that should be usable by itself for a small-scale project.  It might seem "overkill" in a way to use a modular framework with only one module, but there are advantages (such as when project requirements unexpectedly grow and the project isn't so small-scale anymore).

---

James, can I quote/paraphrase you on this in the Official DQMH documentation?

[drjdpowell]

Sure, no problem, Joerg.

[FlatCat]

I called it "the documentation", but right now, all I can find is this third-party web site that mentions the the medium/large recommendation. I thought I had seen iit in the official documentation, but I've read a lot of different things on DQMH by now.

https://testengineerresource.com/2019/12/13/using-delacors-dqmh-add-on-for-lv/

Here's another potential confusion I have related to someone else's writing about DQMH. Sam Taggert (https://blog.sasworkshops.com/simple-dqmh-dos-donts/) recommends in the section titled "Do be very cognizant of coupling" that all modules be arranged in a tree, and that broadcasts only go up the tree and requests go down. In his scheme, if you have a main with DAQ, Analyze, Display, and Log modules, could DAQ, for example, message the other three directly, or would DAQ have to  have to message the Main Module, and then Main would message the other three. Or perhaps I am not understanding what the tree structure would be in this case.

If that is a strong recommendation, it would be good to put in the documentation as well (if it is isn't already there).

[FlatCat]

Joerg,

I found another another reference to the medium- and large-scale project recommendation in section 8 of the Style guide (https://dqmh.org/content/styleguide/)

David