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.