FileMakery, Part I
I have been following Steven Blackwell’s post and comments to it with keen interest. It touches on a pattern of FileMaker polemics I have been mulling over myself. There is a certain tension in the FileMaker community that is often framed in terms of competing philosophies: geek vs. regular-joe, theory versus practice, technical versus non-technical, relational design versus flat design and so on. It is the same tension that has some complaining that FileMaker Pro 8 is still not a sufficiently serious developer tool, and yet others lamenting how FileMaker has become too complex–that it has lost its way because it is now much more difficult to use.
The shape of this debate has been forming for some time now. I think it represents an emerging identity crisis of sorts that, if left unresolved, threatens to push FileMaker Pro into a deeper ambivalence about its future.
What is FileMaker Pro?
In spite of the popular misnomer, FileMaker Pro is not a "database"; at least, not in the strictest sense of the word. It has an embedded database engine wrapped in an easily accessible interface that together make it a terrific tool based on a database, but calling FileMaker Pro a database misrepresents its real value.
The marketing folks at FileMaker Inc. might disagree with this reasoning. They might even find it convenient to represent the product as a database. I don’t begrudge them their prerogative and may even see their point of view. After all, why not embrace the word if it conveys succinctly, if imprecisely, the idea that this software is about working with data?
I am, however, a fan of calling a thing by its proper name. To the extent that everything in FileMaker revolves around the structured storing and retrieval of data, the concept of a database is integral to the product’s and use and identity. However, while it is necessary to think of FileMaker as having a database, it is not sufficient to define it as one.
Put in another way, FileMaker does not aspire to be a database in the way MySQL or MSSQL aspires to be one. It doesn’t belong in the typical database category and perhaps, the problem or benefit depending on your outlook, is that it really doesn’t belong in any neat software category.
Instead, FileMaker Pro is both a productivity tool as well a database application development environment–with emphasis on the application bit. So, while we like to call ourselves "database developers", what we mean is that we are users of a data-productivity tool or a developers of data-centric software. This isn’t simply semantic fussiness. Without a basic clarity around how FileMaker Pro is used and by whom, it would be impossible to speak intelligently about how the product should change.
In my view, FileMaker Pro is special because of its unique ability to address both user productivity needs and information management problems in a data-centric workplace more so due to its application development features than to its database features. The later is convenient but the former is essential.
FileMaker Pro empowers people. It lets non-technical people get big results with a relatively small amount of effort and without a deeper understanding of databases, software design, security or other "high" disciplines. It allows for rapid transformation of ideas into working solutions. It is forgiving–it lets people work in an ad-hoc way that appeals to the spirit of getting things done over getting things technically right. There is a disruptive aspect to FileMaker in that it lets non-technical professionals circumvent the traditional technology barriers to information management (IT) in a way that can be fundamentally scary to the conventional IT mindset.
The point is that FileMaker succeeds where other tools fail precisely because the requirement for success is not technical knowledge. This is a good thing, but it is also a problem. The very features, or the lack thereof, that make FileMaker easy to learn and to use as a workplace professional’s "survival tool" (George Hutchinson, June 01, 2006 on Gladly Would He Teach, and Gladly Learn) can be limiting to the professional software developer. FileMaker Pro’s features are geared towards productivity and rapid development, as opposed to more traditional software development concerns such as reusability of code, scalability and raw performance. Happily, working professionals who probably make up the greater part of FileMaker’s user base are principally concerned about the making things work specifically for "me" or "us" rather than making things work generally for "others."
FileMaker excels at dealing with local and specific data-related problems. I find that developing a FileMaker solution that works for a particular office or business is an order of magnitude easier than developing solutions that work across similar kinds of offices and businesses. This partially explains why it is easier to have a FileMaker consulting practice than a FileMaker software development practice. That line of thought deserves a deeper treatment that I’ll save for a later post. I am merely pointing out that while there is a healthy thrust to push for more rigorous FileMakery, in general FileMaker solutions should be judged by the context and scope of the problem they were intended to solve. "Best practices" that satisfy higher technical standards but aren’t necessarily appropriate to the core of FileMaker’s community–the working professionals doubling as non-technical developers, domain experts, and productivity users. The solutions by themselves may not meet higher professional software standards, but they often work well enough. In spite of their technical weaknesses, they are sufficient to purpose, sufficient to the context in which there were born.
I do, however, agree that greater education and more advance training is a good thing, but we should not overstate the importance of technical knowledge. For me, the test for whether a feature of FileMaker is successful isn’t whether Corn Walker can look good using it but whether Jane-the-travel-agent can as well. And that, I believe, is FileMaker Inc.’s core vision.
I may not completely agree with it, but I respect FileMaker Inc. for their consistency. True, the execution of that vision may not have always been spotless; I’ll be the first to say that XSLT as a replacement for CDML was a tad misguided. Such missteps not withstanding, it seems to me that FileMaker Inc.’s trajectory has been and continues to be squarely aimed at non-technical developers and productivity users. Consider the list of features touted in 7/8: PDF Maker, Excel Maker, Fast Send, Fast Match, New layout alignment tools, Email merge, point-and-click-drag-and-draw relational graph, pour-and-serve tab controls, auto-complete, calendar drop-downs. These features are about "saving time", read "getting things done without the pain of programming." Consider also that FileMaker Pro Developer has been renamed (more appropriately, I believe) to FileMaker Pro Advanced. If there is a sense that FileMaker Inc. is dragging their feet about becoming a more serious software development platform, I would say that the evidence before us supports a deep sense of ambivalence if not an outright lack of internal support for that direction.
To be clear, I am not suggesting that FileMaker Pro is short on advanced features. Lately, there have plenty of impressive additions to the product line, particularly in FileMaker 8 Advanced, such as script variables and custom functions that enhance the programming capabilities of the platform. But, as a whole, I’d argue that these advanced features only do more to set FileMaker Pro apart as a powerful tool for people who are trying to solve problems of the workplace than it does as a platform that addresses the needs of software professionals.
[to be continued in Part II]
The advantage of .FP5 over other products was that .FP5 was drop dead simple. If FileMaker adds complexity , they will lose.
I once asked FileMaker VP Keith Robinson if FileMaker would ever consider releasing an “Enterprise” version of FileMaker, with all the requisite bells & whistles. He said no way. That is not FileMaker’s market.
FileMaker, Inc. has added a great amount of power, and concomitant complexity, in versions 7 and 8. They didn’t lose. Neither have developers who invested time, effort, and yes money, in keeping ahead of the power curve.
There are some people who did lose though: those who either couldn’t or wouldn’t invest the effort to stay ahead of the status quo. This trend likely will continue, with ever changing classes of winners and, yes, of some losers.
Steven H. Blackwell
IMHO, FM 7 was only “more complex” to those of us who were used to .fp5. I suspect that for the beginning user, .fp7 is easier in many many ways.