Multiple Developer Solution Design

From Dwayne Wright - www.dwaynewright.com

This topic jumped to my mind because of a situation I’m in at the office. We have a tight deadline on a large FileMaker project and we needed to pool our development resources in order to finish it properly. At first, it was just two developers working on different areas of the same database. Then another developer needed to jump in to wire up the integration between that database and the accounting software package called QuickBooks. Then one of the original developers needed to step out and I stepped in. So just in case you are confused, the current count is three developers working on the same solution at the same time.

In this case, the multiple developers working on the same project at the same time came out of necessity. However, it was something we had been talking about for quite some time. There have been posts to some of the FileMaker forums and openly discussed in various FileMaker developer meetings like FMPug meetings and the annual FileMaker Developers Conference. For the most part, these discussions were centered around “Why Can’t We” or “Why Doesn’t FileMaker Allow Us To” discussions. This is because FileMaker (the application) wasn’t designed to be developed like this. However, with each new released version of FileMaker, it gets a little better in the area of multiple developer design.

I should say that concurrent FileMaker developer design does require a copy of FileMaker server. I would never recommend it under any other set of conditions. This way, if one of the users machines crashes, the database files are 99% just fine. In my office, all FileMaker design work is done with the files on a FileMaker Server.

I would also never recommend this design method for junior FileMaker developers. However, a team of professional FileMaker developers can make a lot of development headway in a short amount of time.

There are some limitations in concurrent FileMaker design. Only one user can save changes done in the Define (tables/fields/relationship) dialog box at a time. This is true for ScriptMaker as well, up to FileMaker 9. I do believe that this new feature of FileMaker 9 probably requires that the server and all the developers to be using FileMaker 9 as well. Normal practice in this situation is to have everyone using the same version of FileMaker across the board.

One way to overcome the above limitations is to have a FileMaker solution using more than one file and have a developer working (primarily) on a file of their own but still contributing to the design of the overall FileMaker solution.

Another little odd tidbit is that one developer can write a custom function while another developer is defining a calculation. Although this isn’t a magic bullet for the concurrent developer limitations, it does allow for some interesting opportunities.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2007 - 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.