Rebuild Or Repair: What An Inherited File Asks You

Overview

Someone hands you a FileMaker file built by another developer. Two hundred scripts, no documentation, and a deadline. The question on the table is always the same. Repair it, or rebuild it.

Before you answer, run one test.

Test the file first

Pick a field that looks unused. Remove it. Count how many scripts break.

• three scripts break, and the file is more tangled than it looks
• twenty scripts break, and every part touches every other part
• none break, and the file is more modular than you expected
• you cannot even find every place the field is used, and that is its own answer

The number tells you what kind of file you are actually holding.

How many days can you lose

Ask how many days the business can run without this system. Not how many days you would like. How many it can actually survive.

A file with three days of slack lets you rebuild in stages, one module at a time. A file with three hours of slack does not. That number sets your timeline before anything else does.

Then weigh the hours honestly. Reading and understanding two hundred scripts written by someone else can take longer than writing eighty new ones that do the same job. Old code with no comments is not free just because it already exists.

It depends

Repair when the scripts are simple, the field count is low, and removing one field breaks almost nothing. The learning time will be short and the file already works.

Rebuild when the file fights you at every field, the days of slack are wide enough for the work, and learning the old logic would take longer than writing new logic.

How many scripts break when you remove one field from the file you are running today?