Six Fried Rice

When I came to Six Fried Rice as a novice developer, I was essentially a completely blank slate in terms of development style and processes. Luckily, Jesse and Geoff are anything but novices at this. They’ve been working with Filemaker long enough to have made all the mistakes I was likely to see, so when it came time to train me on how best to follow the Six Fried Rice methodology they had a pretty broad set of standards and processes ready to go. Those processes have helped me really understand and develop solid, easily understandable and extremely stable systems that if I had been left to my own devices would have taken me years to figure out.

Due to a pretty solid interest that was expressed at this year’s DevCon and a desire to fill in some of those long gaps that tend to pop up on our blog I’m going to be writing several posts that will take you through how we develop at Six Fried Rice from start to finish. There is going to be a combination of more general concepts such as Data Separation and more in depth views on error handling, custom functions and parameter passing. To start it all off though I’m going to start at the absolute beginning. The Data Separation Model.

Data Separation is the concept of isolating the critical business data from the UI and scripts that act upon that data. Here’s an example of how this works out:

Let’s say you have a system that tracks inventory, creates invoices and allows you to enter orders. If you aren’t following the data separation model then you’ve probably got one file containing all of the data tables as well as the scripts and layouts. Any time you need to make a change you have two options. You can either work on the production environment and risk messing up the live data that whoever is using this system relies on or you can work on an offline copy of the file. Both of these methods have some pretty significant disadvantages. Working on the live data of a company isn’t a bad approach for most minor changes and updates, but when you start doing schema changes or drastically altering the scripting that drives the system you run the risk of seriously affecting the business of your client. On the other hand, if you take an offline copy of the files to do major updates you run into the problem of getting those changes back into production. You can’t simply swap files since while you are doing updates your client is making changes to the data in his copy. Testing out the changes offline and then just reproducing them in the client’s file is a huge redundancy. This is where data separation comes in.

Instead of having just one file that contains all the data, scripts and layouts for the entire system let’s divide the data out into its own separate Basefile and stick the layouts and scripts into another file called UI. Now, let’s say you need to do a major system upgrade that’s going to involve changing most of the core scripts in the system and adding a few new layouts. You would just need to get a copy of the UI file, do whatever development and testing you would need against it and when you are ready you can simply swap out the UI files. Since all of the actual data is in its own independant file you don’t need to worry about your client’s data being out of date and you pretty much entirely avoid the problems associated with data migrations. This gives you an exceptional amount of freedom when it comes to trouble shooting and upgrades to your system.

Now, this is not a fool proof system. If the changes you need to make are changes to the actual data structure itself and the relationships that the system needs to function correctly you will still need to do those upgrades to the production system’s Base File. However, there a few development processes and scripting techniques that help to offset this problem and reduce how heavily we rely on the data structures themselves. I will go into how we structure the actual data infrastructure to keep the total number of fields to a minimum in my next post and go over the scripting aspect later on. Basically, we develop around the idea that data gathering and manipulation should be done by passing parameters into a script that is completely context independent, letting the script gather the information or make the change rather than attempting to do so through a relationship or calc field and then having the script return a result that we can make use of if we need it to. We’ll get into this at a deeper level on a later date.

Data separation is one of the key concepts that we integrate into any system that we build. The ability to simply grab a copy of the UI file, make whatever changes we need and test them offline without having to worry about the state of the client’s data makes it possible to avoid quite a few pitfalls. We never have to touch the production environment, data migration is never a problem and development can then be done entirely free of worrying about stepping on user’s toes. The drawbacks include having multiple files that you have to maintain and making changes to the actual fields is a little tedious, but these seem to be small prices to pay for the freedom to manipulate the core system functionality without having to worry about the data.