When I find myself journeying into an unfamiliar FileMaker database environment, I wade through a slew of custom functions, machete my way through the tangles of relationship diagrams and find myself with an immediate migraine. Taking over a new solution from another developer is no simple undertaking and many developers lose their bearings trying to spend time restructuring and enhancing areas that don’t need it. If we can better understand the roots and skill level of whom we are adopting the database from, then we can know how to approach the optimization process effectively and efficiently.

To Optimize or not Optimize, that is the Quandary

As I was working in my adopted solution, I ran into the proverbial fork in the “relationship graph” scenario: SQL vs changes to the relationship graph. Summary fields were being used to calculate totals on a report and I had to expand upon the report using either more summary fields or writing SQL statements to grab the data and summarize with calculated variables. In this scenario, I tested both methods out of curiosity. For me, the process took twice as long to get the SQL statements working properly as it would have to build upon the relationships. SQL only increased the speed of the entire process by a miniscule amount.

Despite the disadvantage of complicating the schema, I ended up using the relationship method, because of the likelihood of needing to add more complex searches and related finds for this report. SQL would normally be my preferred method in an adopted database because the structure usually doesn’t allow me to grab exactly what I need right off the bat. However, the previous developer built this before FileMaker’s SQL ability was introduced, so the schema was essentially in place. It still begs the question, Is it better to tear down and streamline or work with what we have to save time?

Do we as developers spend too much time, up front, worrying about potential overhead of code and structure?  As referenced in a previous blog post by John Newhoff of Portage Bay Solutions and According to Tony Hoare, “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Bring your Compass

Most likely there are problematic or even obsolete areas of any database that has been under development for many years. How do we know what to fix and where to start looking in the first place? When lost in the woods, having a compass can be a life-saver. The compass in the FileMaker forest is a DDR analyzer. If we really want to consider proficiency and optimization, a tool like FMPerception can be extremely effective and a headache reliever.

Even in databases we build and are familiar with, DDR analyzers can guide us right to where the system needs to be optimized. Efficiency starts with the right tool and a DDR analyzer is a developer’s multitool.

Let a DDR analyzer help guide you to:

• Unused tables and relationships to remove and unburden your solution from superfluous structure. 

• Broken references in scripts.

• Summary fields that may be hidden on a layout

• All layouts a certain script is referenced from (My favorite)

• Unnecessary commit record and refresh window steps in scripts

In the past, I would aimlessly wander through the system trying to find one problematic summary field or looping script trigger on a hidden object. No longer do I burn the midnight oil digging through seemingly endless amounts of layouts, scripts and relationship diagrams.

Make Yourself at Home

The solution may feel like a foriegn country at first, but it is now in your hands and should feel more like home each and every day.

• Add your standard naming conventions to tables and relationship graphs.

• Organize your script and layout managers into appropriate folders.

• Use a DDR analyzer to do a little spring cleaning of superfluous tables, layouts, scripts and relationship instances.

• Reorganize and clean up the relationship graph to make sense to you.

After these changes I can move forward with more clarity, not feeling as overwhelmed anymore. These steps may seem obvious and insignificant at first, but doing so as soon as possible has helped increase my proficiency and made the database feel like a familiar application.

GetSummary(This Blog Post)

Developing in a new, unfamiliar system takes time, trial and error and multiple migraines before we can instinctively know exactly where and when to optimize. As true problem solvers in this workplace innovation platform, optimizing your FileMaker system starts by optimizing your time. I believe there is rationality in the phrase, “premature optimization is the root of all evil.” However, it is still extremely important to have the expertise to know when and where to optimize. We have great tools at our disposal and if used correctly, we can not only improve our solutions, but also ourselves as developers.  Hopefully, these tips and experiences will give you some direction as to how to get out of the woods of taking over a solution from another developer.