When FileMaker Design Gets Too Smart

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

*** this is one of my rare soap box rants, so feel free to pass on the task of reading it (grin) ***

With any advanced technique, it is possible that one developer will take an opportunity farther than another developer wants to deal with. There are FileMaker developers out there that are so interested if something could be done, they ignore addressing the question if it should be done. The amount of unnecessary technical debt they pile into a solution ultimately gives FileMaker developer a bad name. Although these developer are normally brilliant, their "look at how brilliant I am" behavior damages anyone that has to maintain their solution after they walk away from them.

If you run across one of these databases, please don't think of it as typical FileMaker design. It is quite possible that you may have to refactor part of the solution or start from scratch.

Case in point, I had to walk away from a project that had this problem. There is a product out there that uses a massive amount of custom function programming along with script variables. In fact, this trickles down to areas a simple as the title on a button. Seriously? Multiple custom functions, script variables and other complexities to manage the name on a button? I am totally against this type of programming because it isn’t manageable for the long haul. It particularly is a problem when you are the third or fourth developer at bat for a solution.

In this situation, one of the tasks was removing a charting button that appeared on four or five layouts. However, the button wasn’t a simple button. It was a repeating calculation field (for the label) and an invisible button graphic on top. Don’t get me started on invisible buttons, that is another thing I simply hate to come across. They are also something that looks like a good idea for the first developer to add and cause nothing but problems with the third or fourth developer has to deal with them when the original developer is unavailable or unwilling to deal with them.

Anyway, the title of the button that I was suppose to remove was the fourth repetition of a six repetition field. You cannot remove a middle repetition and have other repetitions slide to fill their place. In particular if there are calculations that are repetition specific, you might not know how your edit will affect the overall operation of a solution. To make matters worse, the calculation had a different syntax for each repetition, which referred to a custom function, which managed a huge number of tasks from two different global variables set during startup and edited during the execution of the solution.

All of this coding for “just the title” a button that appears on four layouts that runs a script that has a half dozen script steps. Sometimes, going to the store for a quart of milk is just that. You don’t have to toss the experience into an array of your life experiences and then parse that array if you want to go to the store for a quart of orange juice instead.

The term of KISS (keep is simple stupid) doesn’t fit because the coding, standing on its own, is brilliant. It just isn’t modular enough for the blue collar purposes that are always the workhorse purposes of a database core. I tend to think of this as a simple edit of KISSG (keep is simple smart guy/gal).
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.