FileMaker Extra: Development with a Team

FileMaker Extra Development with a Team

Sometimes systems are big enough that they warrant multiple developers in addition to multiple users. Developing as a team can be a bit complex with FileMaker Pro, but one of the best (and often unsung) features of FileMaker is that database schema changes can be made while the database is live, on a server, as other users are in the system. This is an extraordinary boon for FileMaker developers and will make a real difference in all of our lives.

The idea is simple: Set up a server (far better than multiuser peer-to-peer hosting) and have as many developers as a given system needs work together.

It's important to keep a few things in mind: Only one person can adjust the schema in a given file at a time. This is true for editing scripts as well. If another developer is working in ScriptMaker, you can view scripts there, but you will be unable to make changes or add new scripts until your teammate is finished. This means you can have one person focused on scripting, one defining a new calculation field, and a handful of others working on different layouts all at once. One way to avoid conflicts in this regard is to split your solution into multiple files and have those files reference external table occurrences as needed.

Over the years we've assembled some best practices for working on a team. Here's a list of techniques we draw on:

• Use FileMaker Server Server (as opposed to simply working peer-to-peer) allows you to run frequent backups, and if any one machine crashes, the files are still protected from the crash.
• Use FileMaker Pro Advanced The Script Debugger is handy to use in the multideveloper environment, and the Data Viewer is an invaluable tool as well. When another developer is editing scripts, and you can't open a script in ScriptMaker, turn on the debugging tool and you'll at least be able to see the script in question.
• Use custom functions Custom functions can be written while other programming activities are underway, and they provide a deep layer of possible abstraction. It's possible to have multiple developers building custom functions while others work in the core system, and it's also a great way to reuse code across a team.
• Set up a bug-tracking database If you're working on a multiuser system, testing, requests, random ideas, and other communication is vital. You've got some of the world's best database software at your fingertips; put it to use and build a bug-tracking system for your development team and your users.
• Build re-login scripts, toggle status area scripts, and developer layouts Giving developers access to the back stage area of a system is vital. Build scripts to get them there.
• Assign a chief architect With creating a meal, too many cooks in the kitchen spoils the broth. Similarly, one person should ultimately be responsible for the overall technical directions the system requires.
• Comment Comment. Comment. Comment. Your team will either thank or kill you, depending on how well you take this to heart.