What metrics do you use (or would you like to use) to assess the quality of a FileMaker database?

[Dave Ramsey]

When first looking at a new system, what indicators would you like to see that will tell you about the quality of the system?

When looking at a system you’ve been working on for years, what are some signs of mounting technical debt?

 

I’m looking at a feature to provide some top-level indicators about system quality.  Granted, a lot of system quality is about the way in which things are put together, the quality of the design, etc.  But are there things that you look for, and when you see them you know it’s going to be a problem?

 

What says, “this is going to be an unmaintainable mess?”

Conversely, what says, “somebody had their head on straight when they made this?”

 

Please don’t worry about how hard it will be to calculate.  This is just idea generation.  I like lots and lots of bad ideas.  We'll worry about what's "possible" later.

[jbante]

Cyclomatic complexity!

[Dave Ramsey]

43 minutes ago, jbante said:

Cyclomatic complexity!

Jeremy, if I calculate cyclomatic complexity for each script, how would you prefer to see a system level summary expressed?  The average?  Min/Max, Average? Average & standard deviation?  Chart of scripts by cyclomatic complexity?  What would be most useful to give you a snapshot view of what's going on, cyclomatically (so to speak)?

[john renfrew]

Would like to know all the objects/fields on a layout that have quick find turned on, so I can turn off the ones I don't want... Problem is some of them are inside popovers inside sliders....

[Wim Decorte]

When I get into an existing system and do an analysis, here are some of the quick metrics that I am looking for:

# of fields per table

# of TOs vs tables

# of calculations / summary fields in relation to regular fields (broken down in stored and unstored)

# of layouts with more than one portal

# of relationships with multiple predicates (in relation to total # of rels)

# of sorted relationships (in relation to total # of rels)

# of local CSS overrides per layout

# of custom functions

Quick inventory of what plugins and what calls they make

 

 

[Dave Ramsey]

5 hours ago, john renfrew said:

Would like to know all the objects/fields on a layout that have quick find turned on, so I can turn off the ones I don't want... Problem is some of them are inside popovers inside sliders....

So, would the count of fields with QuickFind turned on (or maybe a percentage) be a metric, or are you just looking for a way to locate these?  

If you just need to locate them, it's already possible in FMPerception.  Every list of layout objects (either for a single field, or for a whole database/solution) has a "QuickFind?" column.  If you sort by that, you can use the Hierarchy display in the Detail to find out how to get there (regardless of how many layers it's hidden within).

[Dave Ramsey]

4 hours ago, Wim Decorte said:

When I get into an existing system and do an analysis, here are some of the quick metrics that I am looking for:

[...]

Great list, Wim.  Thanks!  A couple of quick clarifying questions:

Quote

# of sorted relationships (in relation to total # of rels)

If a relationship is sorted in both directions, is that one sorted relationship, or two?  I know we don't see a *lot* of bidirectionally sorted relationships,  but...  Alternately, perhaps "Bidirectionally sorted relationships is separate metric.

Quote

# of local CSS overrides per layout

Is that "number of objects with overridden CSS", or "number of overridden nodes"?

Quote

Quick inventory of what plugins and what calls they make

I have not used every plugin out there.  Can anyone think of other plugins that follow the MBS style of making the call a parameter, rather than part of the name of the function?

[john renfrew]

Hmmm.. Maybe what I would prefer is the ability to export JUST a selected set to CSV then..

With a really big file and lots and lots of objects I can do the export to CSV, bring into FM and then delete the records without QF on, might be nicer to skip one of those steps.

I am aware the CSS is hidden inside the XML nodes which makes it a two level search, but I would love the ability to walk the whole DDR and look for all fonts which are being used as the first step to something more useful..

john

[Wim Decorte]

5 hours ago, Dave Ramsey said:

Great list, Wim.  Thanks!  A couple of quick clarifying questions:

If a relationship is sorted in both directions, is that one sorted relationship, or two?  I know we don't see a *lot* of bidirectionally sorted relationships,  but...  Alternately, perhaps "Bidirectionally sorted relationships is separate metric.

that would count as two.

5 hours ago, Dave Ramsey said:

Is that "number of objects with overridden CSS", or "number of overridden nodes"?

For the first pass of just getting a feel for the solution just the # of objects would do.  If I needed to screen for performance then the # of nodes would be useful.

 

5 hours ago, Dave Ramsey said:

I have not used every plugin out there.  Can anyone think of other plugins that follow the MBS style of making the call a parameter, rather than part of the name of the function?

I don't use the MBS plugin so I don't know.  But basically a list of the external functions calls would do as a start.

 

[webko]

Basically what Wim said, and also I look for fields named with numbers in them (Address1, Address2, Year2015, Year2016) as they usually indicate poor design, and ID fields that are not obviously ID fields

[OlgerDiekstra]

On 02/07/2016 at 9:51 PM, Wim Decorte said:

When I get into an existing system and do an analysis, here are some of the quick metrics that I am looking for:

# of fields per table

# of TOs vs tables

So more TO's than tables is better?

On 02/07/2016 at 9:51 PM, Wim Decorte said:

# of calculations / summary fields in relation to regular fields (broken down in stored and unstored)

# of layouts with more than one portal

Multiple portals on a layout is not good?

On 02/07/2016 at 9:51 PM, Wim Decorte said:

# of relationships with multiple predicates (in relation to total # of rels)

# of sorted relationships (in relation to total # of rels)

Does that mean sorting relationships is something we shouldn't be doing?

On 02/07/2016 at 9:51 PM, Wim Decorte said:

# of local CSS overrides per layout

# of custom functions

More CF's is better? Especially in larger solutions? As long as they are used to reduce redundancy in code?

On 02/07/2016 at 9:51 PM, Wim Decorte said:

Quick inventory of what plugins and what calls they make

It's an interesting list, and I'd like to understand more about the rationale behind it.

[Dave Ramsey]

OlgerDiekstra, to answer for Wim (and if what i'm about to say misses his intent, I'd love to be corrected), these are just expressions of complexity.  In some of these, really low numbers might be almost as bad as really high numbers.  

If you have a system with 800 custom functions, that's a problem.  That said, a big system with zero custom functions might speak to either the processes used, the tools used, or the overall age of the system.  Certain kinds of calculations are going to much more verbose if no custom functions have been used.

One or two sorted relationships aren't necessarily a problem until users start complaining about performance. 127 sorted relationships is a design problem almost any way you slice it.

20 tables with zero TOs speaks to a design philosophy, and a set of techniques that would almost certainly be required.  20 tables and 200 TOs is going to make it tough to make changes.  The "same" relationships are represented dozens of times,and if you want to change one, you likely need to change it in many locations.  Systems created prior to FileMaker 7 will sometimes have a tendency to have many more TOs than tables (due to the way that relationships used to work).

More than one portal per layout is also about complexity.  If you'll grant that a layout with 5 portals is more complex (in UI, UX, and code) than one with 1 portal, the same can be said about 2 or 3 portals when compared to just one.  Wim's drawn that line at "1 is fine, 2 is pushing it".  One layout with more than 3 portals?  Not a problem.  45 layouts with 2 or more portals?  That might eat some time in unraveling.  It's certainly going to be more complex...

1 hour ago, webko said:

[...] and ID fields that are not obviously ID fields

Webko, can you provide some clarification on what you mean by that?  Are you using a naming convention?  Or some other mechanism for visually identifying ID fields?

[webko]

When I pick up a system, I will often find fields that are actually Primary or Foreign Keys hidden away with no naming convention being used - I change them when I find them, but it's always a drag on my dev time tracking them down.

Customer, Event and ArtWork were all in one of my current systems, and used as keys... And one of them wasn't even actually a key for a connection to the Artistic Works table, but a different table altogether...

[Wim Decorte]

42 minutes ago, OlgerDiekstra said:

So more TO's than tables is better?

Multiple portals on a layout is not good?

Does that mean sorting relationships is something we shouldn't be doing?

More CF's is better? Especially in larger solutions? As long as they are used to reduce redundancy in code?

It's an interesting list, and I'd like to understand more about the rationale behind it.

Dave is spot on with his interpretation of the list.  It's about getting a sense of the complexity and the design.

I would expect a solution to have more TOs than tables but not to a skewed ratio.  10 tables and 1,000 TOs is going to make me frown.

Same with very wide tables,  Same with no CFs or an unmanageable # of CFs.

The portals per layout: very often I'm called in to analyze the performance and # of portals per layout has been a very accurate prediction of performance problems throughout the solution because it *may* indicate a lack of thought on how FM loads data.  Having a few dashboard-type layouts in a solution will not trigger that of course.  In the end it's just about getting a "first sense" of the solution, not an immediate judgement.

[Ocean West]

warnings for things that could present issues -

• mismatch data type for relationships Number to Text may fail 
• trace variables in scripts identify potential lost of data type when setting a variable to another variable. 
• correlation between sorted relationship vs sorted portals and where duplicitous sorts could introduce performance penalties.

[LaRetta]

... and cascading calculations ( calculations which reference other calculations which reference others calculations ).

[jbante]

On 1 July 2016 at 1:30 PM, Dave Ramsey said:

Jeremy, if I calculate cyclomatic complexity for each script, how would you prefer to see a system level summary expressed?  The average?  Min/Max, Average? Average & standard deviation?  Chart of scripts by cyclomatic complexity?  What would be most useful to give you a snapshot view of what's going on, cyclomatically (so to speak)?

When I want a summary of a whole solution, max and median. When I want to decide what to do in what order, an ordered list. Note that custom functions can also have cyclomatic complexity, though it may be a bit more work to calculate.

[Dave Ramsey]

1 minute ago, jbante said:

Note that custom functions can also have cyclomatic complexity, though it may be a bit more work to calculate.

Yeah. I figured that was the case.

If I call a custom function in a script, does the cyclomatic complexity of the custom function impact the cyclomatic complexity of the script?  I'm thinking that way madness lies... but I'd rather have the true answer than the easy one (if at all possible).

[Dave Ramsey]

By the way, I'm not going to have an opportunity to start moving on the results of this discussion until after DevCon.  So, as you're catching sessions in Vegas, and you think of something else, please come back and add it there.  DevCon should make a wonderful seed for brainstorming.  :-)

[jbante]

On 4 July 2016 at 1:59 PM, Dave Ramsey said:

If I call a custom function in a script, does the cyclomatic complexity of the custom function impact the cyclomatic complexity of the script?  I'm thinking that way madness lies... but I'd rather have the true answer than the easy one (if at all possible).

I'm inclined to say no. A script's complexity doesn't increase when it calls a subscript. Why should a custom function be any different?

[HazMatt]

BaseElements has an "Overview" layout that has a nice list of element counts.  There are columns for Count, Errors, Unreferenced, Warnings and Performance.  Errors are in red.

A report card containing raw data of that kind (and perhaps a few subjective grades) would be very helpful to get a quick idea of potential issues.