Reinventing the Wheel
by Brian Dunning
article | del.icio.us
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:
- 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
- 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.
- 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.
- Any module is going to be full of stuff you won't use, and it will be lacking
important things that you need.
- 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.