FileMaker Pro is a uniquely versatile tool. Knowledge workers can use it to produce much needed workgroup-level databases out of the box. On the other end of the spectrum, high-end features make this same easily accessible development environment sophisticated and robust enough to support low-volume enterprise systems. As this happens, development practices need to change in predictable ways. This article focuses on what some of those changes are, and explains how best to make them. If you're near the start of your FileMaker Pro development career, you'll get an idea of what likely lies ahead. If you're further along, you might be experiencing these issues already. The good news is what's best for you professionally as a developer is also generally best for your employer or customer. At the same time, there are some blind alleys to avoid.
Core crafts and development diet
There's usually quite a difference between the skillset you study, learn, get certified in, etc., and what you end up using regularly. I use the term "core crafts" to describe that first kind of learning. My term "development diet" refers to the knowledge and experience you use in your daily work. Core crafts learning is more on the level of theory: You've worked through some exercises, but have yet to experience how the tool behaves in extended usage. Development diet knowledge is practical and detailed in ways that test questions can't explore. It involves shortcuts and pitfalls you learn only from experience, the kind of information discussed on technical e-lists and forums. It's the practical applications that arise from pushing a feature set to meet real-world needs.
FileMaker Pro itself, the balance between desktop and Web applications, and ways of doing business or science in general -- are changing quickly. Therefore, learning and the need to update your core crafts knowledge base never goes away. Everything I talk about in this article assumes you know, update, and sometimes extend your core crafts. Although it involves work, and means keeping an eye on development trends, in fact, you get used to it, and in some ways it gets easier. You'll recognize new things and understand them as extensions of what you already know. Managing your development diet, on the other hand -- particularly if you work in-house, or are a consultant dedicated to one or two customers -- can often become harder, rather than easier.
Why good diets go bad
Let's look more closely at the core crafts versus development diet distinction. When you start building new solutions, your development diet is rich, challenging, and rewarding. With a clean slate, you can use the latest tools, mold them creatively to project requirements, look for efficient architectures, write clean, understandable code, and (hopefully) document it. Even if you don't have enough time to document it well, it's fresh in your mind and you understand it. At this stage, your core crafts and daily development diet are entirely in sync. You bring your newest knowledge into your practice on a daily basis. It's easy, it's almost automatic, and for a developer, it's great. The problem is it doesn't stay that way. In fact, over the lifecycle of a solution, it's typical for the two to get out of phase.
As time goes on, you can easily become the maintainer, extender, and sole support person for the successful applications you build. More of your time is devoted to tasks such as:
- Periodic (quarterly, or other cyclic) system parameter resets
- Tweaking existing functionalities or adding new ones
- Database integrity clean-ups (orphans, de-duping)
- Requests to slice and dice data in reports in ways not originally intended
- Chasing small but persistent bugs
- File maintenance (compacting, pruning indexed fields, etc.)
- Teaching new users and supporting older ones
- Power-user chores you can't or don't want to delegate