In 2005, FileMaker Inc. released a white paper which proposed possible
methodologies and conventions under which a FileMaker developer could
guide their development of a FileMaker solution. It was both a
collaboration and contained contributions from a number of
well-respected developers.
Here is the PDF:
FileMaker Development
Conventions
Interestingly, the document opens with a statement about FileMaker's
flexibility and laments the "constraints or concerns other developers
experience".
FileMaker developers have the freedom to rapidly create and modify
applications without having to deal with many of the constraints or
concerns other developers experience. When employing an interactive
approach to design, a tool like FileMaker lets you modify and extend
functionality with little regard to dependencies elsewhere in the
solutions. However, the more complex the solutions, the more difficult
it is to maintain.
While the trailing statement about "extend functionality with little
regard to dependencies" is the dead on boon for developing in
FileMaker, these two positions stand in contrast to each other - at
least for me.
Having worked with other programming languages such as PHP and
Java/Groovy and within those, a tightly typed Content Management System
named Drupal, I've found that following a strict set of well-thought-out
standards is far from a "constraint" or "concern".
Rather, the biggest benefit of a strict system is one that is highly
freeing - in that I'm able to think about the solution at hand instead
of the conventions being used. Strong documentation about the system
makes the solution much more maintainable - which is one of the primary
goals of all code.
Further down in the first page of the document, we find the following.
No naming convention can address every conceivable development
methodology and solution design. Furthermore, it would be
counter-productive to try to establish such a rigid rule set.
While the first sentence is true, I highly disagree with the second.
When working with a team of developers, whether in the same location or
spread across the world, it's the very standards upon which you
establish, which promotes the high degree of collaboration which is
possible.
For this reason, and based on my long-time experience with FileMaker, I
am providing my own standards within this public forum. This semi-closed
wiki is open to your comments and feedback. If you would like to become
publicly involved in evolving the standards documented here, then please
contact me by including information about why you would like to become
involved and what you would like to contribute.
My goal is to refine these documented standards and provide as much
documentation about them as possible. As was pointed out in the 2005
document, there are many developers using FileMaker, and no one standard
has been adopted. It's not my goal to make this the single standard.
The goal is to provide one which is well documented and prevent the
beneficiary from having to do so himself or herself. This is leverage
and it's a good thing!
In closing I'd like to comment on the following.
The FileMaker developer base is extremely diverse. The approachability
of the product makes it a clear choice for novice application
developers, and the rapid application development nature of the tool
is attractive to more seasoned developers, too. The amount of effort a
developer needs to apply to naming conventions is different at each
end of the spectrum.
At the same time, the lack of any form of strict conventions is the very
cause of frustration with "novice created solutions" and leads to
development frustration for both novices and seasoned developers. This
is apparent when either trying to understand their own developmental
evolution covered over the course of a "learn-as-you-go development
project" or starting out with zero idea about how one could have made
their project more standardized from the beginning.
For this very reason, I present the genesis of the "ISO Standards for
FileMaker Development".
Sincerely,
Matt Petrowsky