Inquiry - What is your Modularity Index?

[Conseils]

Well I ran a quick survey of previous work.

My most important project 3.8 (172 revisions, over 7 years)...and counting.

On average 4.2, however one project that I have been bashing my head against; that has really caused me some heartache and that I would dearly love to get going has an index of 6.....

Now there's a hint perhaps. I shall divide and conquer.... I hope, or just end up with lots of little bits all over the floor; like I did when I was a kid .

Cheers for the suggestion.

Message Edited by Conseils on 10-16-2007 10:00 PM

[Wiebe@CARYA]

Seems to me there should be a maximum value of MI?

Regards,

Wiebe.

[Spectre_Dave]

A casual observation shows that the -average- # of nodes is related to the Modularity Index (MI).  This measure is displayed below the total # of nodes.

It turns out it is the average of nodes per VI  is 1/MI * 100.

MI   -average-

2   =   50

3   =   33.33

4   =   25

5   =   20.

[Graziano]

...in fact this follow from MI and average nodes definitions....

[Graziano]

---

wiebe@CARYA wrote:
Seems to me there should be a maximum value of MI?

---

I suppose 1 node/ 1 subVI is the upper bound, but it is quite senseless.... (MI = 100 in that case)

graziano

[Wiebe@CARYA]

I think a subvi is considered a node! So, the limit is actually determined
by the maximum depth of subvi's (don't know if there is one):

Max possible MI = Max Nr of VI's / ( Max Nr of VI's -1 ) X 100

And if the maximum depth of vi's is near infinity, you'll get 100...

What I ment was, there should be a recommended maximum. When a
recommendation is that the MI should be above 3, it suggest that a higher MI
is better, but it's probably not. The MI should be above 3, and below 5 or 6
or something?

Regards,

Wiebe.

[F._Schubert]

I think life, creativity and computer programs can't be so simple as to be measured by a simple number. Take the most simple programming enviorment (turing machine or assembler), you can't say that a program will be 'better' if there is more or less lines of code (or CPU instructions), because of other considerations as readability, reusability, performance ...
And once it comes to such sophisticated tools as our beloved LabView, it will really be more a question of taste, depending on your skills, your familiarity with certain aspects, the 'customers' requirements, the size of your screen (try to program with the lowest possible resolution your monitor supports for some weeks, maybe with the old lpatop because your new one is broken and you're off-site, or rotate your monitor by 90° for a new LabView experience)...

I think that MI as well as Bens Hierarchy-Tree-Shape approach will be highly dependend on the architecture of the code. As an example consider the following two cases:
* A UI with a lot of controls (ok, nicely aranged in clusters and using a Tab-Control) with an event structure handling 30 'Value Changed events' (put all new data in a cluster, call some SubVis, forward actions/data through a queue).
* An Action Engine, with a set of wrapper VIs to have the appropriate connector pane with required inputs, all in a cool 4/2/2/4 style and a self describing icon.

I would suppose that in both architectures both metrics would widely differ, while some Ruben-Goldberg Code woul be 'optimum'.

So, if we want to find a metrics to cover our code (indepentend of our style, taste, flavour), we would need someone spending time (maybe a nice Master-thesis for theoretical IT or philosophy) on finding 'limits' for each architecture (and maybe subtype). And when it's published, we already discovered 'better' ways of doing it. 😉

Felix

[MRedRaider]

Interesting.

My older projects have an average of 5. These projects have, to put it simply, archaic architectures compared to what I write today. Lots of brute forcing.

My newer projects that are based on an advanced architecture from top to bottom, I even use queues in my subVIs to allow instant flushing and exit... have an average of 2.9. Having seen this, I decided to calculate the metric on my basic subvi template: 3 user VIs/54 nodes ==>> MI of 5.5. This seems to be a costly architecture for a VI that does nothing.

This metric seems to prefer simple architectures or extremely large applications. Most of my applications stay under or around 5k nodes these days. Maybe I am over-architecting my projects..

Thoughts?

[PhillipBrooks]

Your observation that this metric is favorable of simple architectures or large applications seems to validate the objectives of Peter's book; to write effecient, modular, extensible and easily understood LabVIEW code.

Now I've got to find time to reread the book and finish the modularity VI I started

[Wiebe@CARYA]

I agree that there could be architectures that are functional, and result in
higher metrics. But there is probably an overall maximum. The maximum MI
approaches 100. I'm sure the practical limit is much lower. If we have
enough references, we could establish a recommended maximum. This maximum
might be argued by someone who uses an exotic architecture, but since it's
just a recommendation that is not a problem. People making exotic
architectures are probably willing to break some metric recommendations
anyway.

The danger with having no maximum is the idea that a higher metric is
better. This might in turn result in using the metric as a goal in stead of
a way to gain improvement.

Another thing.. Is the author of the book aware of this discussion? He
should have some interesting thoughts about the subject.

Regards,

Wiebe.