Software Venture Consulting

FileMaker Pro downloads & Resources
FileMaker Custom Functions
FileMaker Web Viewer Examples
FileMaker Pro & Lasso Consulting
Training
FileMaker Books
FileMaker Articles
FileMaker Error Reference

Free Web Tools
Free FileMaker Tools

Personal Pages
Videos
Adventures
Links

Shopping Cart
Shopping Cart

Search:

Free Newsletter
Signup


Contact


Privacy Policy



FileMaker is a registered trademark of FileMaker, Inc. in the U.S. and other countries.

Browse Mode
February 2004

Reinventing the Wheel
by Brian Dunning

digg this article | del.icio.us this article

If I hear another request from someone looking for a $50 off-the-shelf solution for Flying Wing maintenance software for companies operating north of the Arctic Circle who speak Afrikaans and track parts and supplies in cubits and hectares, BECAUSE THEY DON'T WANT TO REINVENT THE WHEEL, I'm going to jump off a bridge.

The analogy is as grossly lopsided as a one-legged elephant. If choosing business software was like selecting wheels for a car, there would be two dozen companies in the world, each with ten million exact clones. The same customers, the same locations, the same employees, the same gross sales, the same suppliers, the exact same products and pricing, and the same corporate philosophy and personality.

Imagine the young design engineer at General Motors or Toyota who, upon being tasked with creating next year's new model, sends in his competitor's blueprints on the principle of not reinventing the wheel. You may state that this analogy is erroneous, because the engineer is supposed to create a market-dominating, unique product; while the software guy only needs to do the same bean-counting that every car company has done for decades. Not true. An effective enterprise software system very much needs to be cutting edge and highly optimized for its dynamic environment. Every system I ever designed for a company is flush with unique tools, decision-support mechanisms that took years for them to define, and bloated with exceptions management and special routines.

I'm also not the only developer who has been approached by a certain personality at a client company, and asked to insert a special handler to pacify a certain other personality. "Bill's kind of a jerk, and he thinks we use the metric system; so could you please make Bill's screen look like this, and make sure he thinks everyone else is using the metric system too?"

And then there are the "modules" that can be "easily integrated." "Let's buy this person's accounting module and integrate it, rather than reinvent the wheel." First of all, the very term "module" is misleading. There are no FileMaker Pro modules. There are plug-ins, but there are no modules. There is no set of standards by which disparate FileMaker systems are integrated with one another, and thus no reason why another person's piece of a solution might easily connect to yours. Here is my list of reasons why integrating a "module" is almost always a silly idea:

  1. It usually takes longer (and costs more) to figure out and integrate the other person's module, than it would take to simply build the needed functionality.
  2. The module is generally cut from a customized system for a particular client, and thus contains all kinds of unique customizations that were designed for someone other than you.
  3. The look and feel of the module's layouts will differ from yours, necessitating some (perhaps a lot of) layout work, and in my experience, pixel-pushing on layouts is always the lion's share of the work anyway.
  4. Any module is going to be full of stuff you won't use, and it will be lacking important things that you need.
  5. Use of a module practically guarantees ongoing headaches down the road. There are many ways to do anything in FileMaker, and the module's author found yet another technique to build his module, which you won't have visibility into, and which will rear up to bite you in a comfortable place when you least expect it.

Even if none of the above were true, FileMaker just doesn't lend itself to modularization. In Lasso or other web languages, you can copy and paste large blocks of code from one project into another. FileMaker doesn't work that way: a given subset of functionality is distributed among scripts, fields, relationships, and layout elements, which can't be easily uprooted from one solution, carried in a nice bunch, and replanted in a different solution with all those disparate elements slipping neatly into place. To say nothing of the integration that then needs to be done.

Am I opposed to the concept of modules? Certainly not. A practical ability to modularize FileMaker Pro solutions would make my life a lot easier. I wish to heck it was feasible. There are people who have claimed to have solved the technical integration hurdles (take such claims with a grain of salt), but I haven't yet heard a module vendor trumpet that he's made something that truly is customized for every possible user's unique needs.

Perhaps the strongest argument in support of my point is the very existence of FileMaker Pro, the ultimate Wheel Reinvention Tool. Just the thing for the Flying Wing maintenance company, and also great for keeping a database of bridges not to jump off.

Brian Dunning

Browse Mode
Jan 10 Solving Performance Emergencies with FileMaker Server
Aug 06 Top Ten Sessions Cut from the 2006 FileMaker Developer Conference
Jul 06 Who's Driving This Thing, Anyway? Or, How Marketing and Engineering Buried the Hatchet (Warning: Contains a Curse Word)
Nov 05 Shingle Grandiloquence
Oct 05 In Celebration of Geek Magnetism
Aug 05 A Rogues' Gallery of Devcon Attendees
Mar 05 Lies, Damned Lies, and Project Specifications
Feb 05 Pick the Right Tool for the Job
Oct 04 Home Media Server Requirements
Jul 04 Leveraging Your FileMaker Lingo
Apr 04 Technical Support Redux
Mar 04 Enforce Seats in FileMaker 7/8/9 Commercial Solutions
Feb 04 Reinventing the Wheel
Oct 03 WAP: The Technology That Wasn't
Aug 03 Brian Dunning's California Governor Election Platform
Jul 03 Sex and the Single Software Developer
May 03 XSLT: Creeping Out of the Closet?
Feb 03 A Consultant's Guide to Traveling
Nov 02 Adventures of Bat Magnum, FileMaker Consultant
Sep 02 FileMaker at Area 51
Aug 02 FileMaker Terminology
Feb 02 Computer Shunts
Dec 01 Aquabase Alpha & the Consultant's Challenge
Aug 01 It IS the Size That Counts
Jun 01 On the Trail of Sasquatch
May 01 Spring Cleaning
Feb 01 FileMaker Mobile Survivor Challenge
Jan 01 Letter from Nürburg
Dec 00 Performance Anxiety
Nov 00 Objection, Your Honor
Oct 00 Leveraging Convergence: Jargon for the 21st Century
Sep 00 Top Ten Things to Do at Devcon
Aug 00 Aesop's FileMaker Fables
Jul 00 Ten Commandments of FileMaker Pro
Jun 00 Explats Cross Examined
May 00 iMac, Therefore iServe
Mar 00 Valley of the Dollars
Jan 00 Are You Up for a Review?
Nov 99 Tales from the Script
Sep 99 Tech Support Revisited
Jul 99 Moderns vs. Classicals
Mar 99 Nashoba, We Hardly Knew Ye