Lack of Respect for FileMaker: Deserved or Not? by Pam Rotella
Like it or not, FileMaker developers often encounter a lack of respect in the I.T. field for FileMaker as a database program. But is that reputation deserved? FileMaker's evolution as a product could be a part of that perception, at least with older professionals who remember specific shortcomings of past versions. But what else could be holding FileMaker back?
FileMaker does have a loyal following outside of the I.T. field, and a minority of admirers within the field. End-users who love FileMaker point to its ease of use. With almost no database skills and a minimal learning curve, a computer user can create a simple database with at least slightly better features than a spreadsheet. The latest versions of FileMaker also offer more available storage and a variety of new and useful features.
Among IT techies, FileMaker is known for rapid development. A preliminary database product can be created in an afternoon, and solutions can be adjusted in a circular pattern of development. Managers can see the product evolve before their eyes, with developers adjusting the product as more specifications are added along the development timeline.
More experienced database programmers who used the program in its early years always appreciated FileMaker's Mac/PC cross-platform technology, rapid development capabilities, and user-friendly GUI. There just weren't other programs like it at the time. Even when MS-Access version 1 was introduced, its design seemed to be based on both FileMaker Pro and Paradox for Windows, but MS-Access still didn't measure up to FileMaker.
However, those now-senior database developers also remember a lack of features that they needed and expected in FileMaker. For example, versions 1 and 2 were non-relational, and FileMaker's first attempts at integrated web design in versions 4 and 5 were primitive. Data and logic separation were difficult to impossible until the version 7/8 rollout. And prior to FileMaker's redesign around its server product, FileMaker's common use of peer-to-peer networking -- making the first person to open a file its host -- often led to slow and freezing databases, based on the speed and memory of the machine that first opened the files.
Among recent I.T. graduates, FileMaker's rejection could be based on academic prejudice. Some I.T. techs don't like FileMaker's features because they were taught other (usually Microsoft-based) programs in college. Often those in charge of I.T. budgets were educated in colleges that don't teach FileMaker, and so they have simply become accustomed to another feature set -- typically MS-Access with Visual Basic to clean up its GUI, and a SQL back end to handle large amounts of data without going corrupt. It's a convoluted way to emulate what FileMaker can handle on its own, but that's what they were taught in school.
The academic world that gave them this standard only reflects what's happening in the field, however. In fact, I've found that the best developers are often light years ahead of the rest of the field, but their better techniques are kept in the realm of "trade secrets" and largely unknown, or at least untaught, to the academic world.
If academics follow the field, then the obvious question is, why is MS-Access the standard PC database in the field? I think the standard answer is that it's a Microsoft product. Microsoft has been able to dominate the field with its products through its history of originally controlling the PC operating system on IBM-compatible machines, and then designing evolving software products to go along with that (also producing parallel products for the Mac). MS-Access comes bundled with the better versions of MS-Office, and so companies use it because it's there. They already have a copy available when the decision is made to start a database.
However, MS-Access usually requires a sophisticated user base, or an IT Department willing to invest a lot of manpower in creating and maintaining databases. MS-Access databases often end when the file goes corrupt or users reach the end of their database skills, with no budget to hire an outside professional and no help from the IT Department. As it is, IT Departments are often suffering from funding and staffing shortages, and have years-long waiting lists for new databases and database improvements. Companies rarely take an interest in whether regular workers have enough database support to reach maximum efficiency, regardless of time squandered on manual repetition of tasks that could and should have been automated.
FileMaker databases often share the same fate as MS-Access databases that are shelved, but with a twist. FileMaker is easier than MS-Access for users who want to create a database, manipulate the data, and produce reports . It's a quick and easy next step for those who want something better than a spreadsheet. FileMaker databases also don't go corrupt as often, and corruption is usually corrected easily with its "Recover" tool. But FileMaker's ease of use and suitability for simple tasks has itself become its downfall, in that its users often have an aversion to seeking outside help when the time comes.
The prejudice that seems to be unique to the product actually comes from FileMaker's own loyal following. If they can't handle a task on FileMaker, then often it's assumed to be a FileMaker problem, not a need for a plug-in or advanced programming skills. Users rarely say such a thing about MS-Access databases; Access is so obviously difficult that it's easy for users to admit when they've reached the end of their own programming skills.
But with FileMaker, everything seems easy and apparent. If a feature isn't obvious in FileMaker's slick programming GUI, then busy user-programmers often assume the feature doesn't exist, or at least isn't worth their time. The IT department may be called in for brief support, providing a few minutes of time as with any technical support request. However, hours of complex relationships, field definitions, and multiple file designs fall outside of the typical techie's time constraints. And so the problem is referred to the I.T. Department for evaluation, where it may languish among many requests for database help, and then finally be evaluated by a technician with little understanding of FileMaker and a prejudice for Microsoft products.
Through the years, I've helped several companies who were investing a huge amount of money in a new system to replace a FileMaker database. They would always give me the same background story -- they were replacing FileMaker because FileMaker couldn't handle their needs. I'm never given the assignment of evaluating whether they really need to abandon FileMaker or just have me fix the problem. By the time I reach them, they've made up their minds, and that decision is that FileMaker goes.
In reality, most of the time FileMaker can more than handle their needs. I can think of only a couple of instances in my career -- during FileMaker's earlier versions -- when a company genuinely needed a relational database prior to FileMaker's version 3, or better external file manipulation than a standard plug-in could provide. But most of the time, FileMaker "not handling" their needs meant that their available in-house staff couldn't understand complex relationships, or didn't want to venture into the world of plug-ins.
Purchasing a vertical application to replace simpler FileMaker databases is often expensive and unnecessary. A company may squander hundreds of thousands of dollars on a single application, often poorly designed and obsolete in a few years, when all they really needed was a single programmer to fix or redesign their programs.
Likewise, it's amazing to me that some companies will spend a small fortune on an entire team of programmers to redesign most company software as browser-based to avoid paying software licensing fees. Software licensing fees typically cost only a portion of one programmer's annual salary, and so any savings on software is lost many times over in the cost of continual software design.
Another problem rarely discussed among developers is that of the worst among us, poor design companies -- rarely discussed because they make us all look bad. Bad developers confirm in clients' minds that even FileMaker professionals can't handle their special needs. Of course, the problem may lie with selection of the lowest bidder, and customers should understand that the cheapest product isn't typically the best product.
I've seen the code created by some of these companies -- disorganized structure and interfaces with no data separation, and only the simplest relationships. I've also seen interfaces so disorganized and decentralized that I was amazed any client would put up with them.
Some development companies charge a standard hourly rate, with the actual programming completed by a new hire with little or no FileMaker experience. Those junior programmers are usually allowed to create flat files with no programming supervision or guidance on conventions from the company's senior programmers.
Clearly, these types of companies are exactly what misleads clients into thinking that FileMaker itself is the problem, that even specialists in the field aren't working out for them. The software itself is blamed, as though the cheapest professional solution is the best that FileMaker has to offer them.
The solution... or not
My observations seem to support the conclusion that the I.T. field's lack of respect for FileMaker comes from a lack of knowledge about the product. Some user-programmers also have trouble realizing that they need programming help when the limits of their own skills have been reached.
I think the best way to solve this problem is to encourage I.T. professionals to learn more about FileMaker, and to discourage them from drawing negative conclusions without adequate knowledge of the product. Companies can benefit from FileMaker's user-friendly design features, allowing many people with zero to few database skills to program their own preliminary products. However, at some point users may need something more complex, and I.T. support staff should understand where user skills end, and technical support needs begin.
Whether a company opts for outside professional help or in-house design is a matter for each company to decide. Developers and IT staff can help, however, by encouraging them to have their needs evaluated by a professional. Some existing FileMaker solutions can be salvaged with a little professoinal help, while others may need a complete redesign, or in fact FileMaker may not be the best product for their particular project.
That's if they'll believe the professionals. Until FileMaker's reputation is fixed, they have so many other people to listen to...
- Pam Rotella is a Senior FileMaker Developer with over 20 years of I.T./PC database programming experience, more than 15 of those years working with FileMaker. She frequently consults with major US corporations and mid-sized companies, and can be reached via e-mail at email@example.com.
DISCLAIMER: This site is not affiliated with FileMaker software company, but rather seeks to provide a forum for credible discussion on software use. Tips provided here are not intended as individual consultation or advice. All papers published here are the opinions of their respective authors, and are not necessarily endorsed by FileMakerPapers.com or Pam Rotella.