Why FileMaker ultimately sucks
When you have a FileMaker "solution" in place, you have a large investment in UI design and usability. You might, depending on the quality of the original design, also have an investment in the database schema. Porting to another environment - say Java + Spring + Hibernate - is daunting, mostly because re-implementing the UI is such a vast undertaking.
As an XPer, I need to be able to test-drive development. The only reasonable way to do that is by using external AppleScript (or Python + appscript and maybe PyUnit too) tests. I don't know about you, but that sounds like far more trouble than it's worth. Just navigating the maze of what works as expected and what requires arcane tricks in the AppleScript world gives me a headache just thinking about it.
XPers also refactor. Not surprisingly, there are no tools at all for refactoring. Worse, the structure and syntax of FileMaker's scripting language actively discourages refactoring. For example, while it's possible to pass multiple arguments into a sub-script, they have to be packed on the caller side and unpacked by the callee - multiple lines of script. And having to drag commands into place rather than just type like a normal human...
Then there is basic source control. A FileMaker file consists of several elements, the most important being
- Tables and relationships
- Scripts
- Layouts
I need to be able to see what's changed from one version of my FMP file to another. Since all the above elements are stored in a single binary file with a proprietary format, it's impossible to do a diff. Sure, one could export a DDR XML file and diff that, but diffing XML?!
And there are indeed tools that purport to do this. Unfortunately, they are universally hard to use and slow, if you cam get them to work at all. (Of the 3 main contenders, I have only managed to get the demo version of one of them to work consistently. The others are so obsessed with license keys that they fail to work at all.)
Labels: filemaker, xp
Comments:
That's all you got? You can't compare file versions? Ha! FileMaker is so fluid, you don't have to document every single little thing. If you are documenting more than that, you are wasting time and don't understand the best attribute of FileMaker which is REDUCING YOUR TOTAL DEVELOPMENT TIME.
"But I work in a team. Our solution is complex."
Save it. Because you are developing in FileMaker, you can cut your team in half. That will save most of your hand-off. Drop the documentation standards and relax. You're in FileMaker. So stop being the guy that complains about sand in your shorts.
As far as passing more than one element, you can use a variable (or a global) instead of a script parameter. But if you want to use multiple script parameters, unpacking them hardly constitutes the entire environment as sucking. It's an annoyance as all environments have a few. It's highly doubtful that this increases your development time by any significant amount. I would suggest less than 3 hours if you added all the time spent unpacking for a full-time developer over the course of a year. Hardly worth discussing.
@comment: Thanks for your comment. I guess you don't understand what test-driven development and refactoring are, or how to foster collective code ownership, or how a development environment should be subject to automation, or what separation of concerns means or...
Oh, whatever.
I am not sure what you mean about documentation. I don't recall ever advocating that. After all that wouldn't be very XP, would it?
But I do see your point - or, should I say I see how you missed my point. Perhaps I should write a more detailed analysis of why FileMaker cannot be used to develop software in an XP world.
That's not to say it can't be used at all. In fact, just today I need to whip up a tool to organize some data, so I turned to good ol' FMP. Of course, as soon as I was done with the task, I quickly deleted the tool that had already served its purpose. It's been a wonderfully versatile RAD tool for 20 years, but it cannot be used for serious development in anything close to a sustainable way - unless you want to take a 20 year step backwards and foreswear all process improvements we've made since then.
But enough. I have to go back (in time) and work on an FMP monstrosity that goes live in a couple weeks. Without tests or even source control!
