Starting again ... from scratch - Opinions wanted on 'If I could start over this time I'd....'

[Cabinetman]

I actually started with v3 but these I did with 5 ... I think.

Anyway! Over the yrs I have learned a lot from different people in here (mostly ... and THANK YOU! ) and incorporated/changed/added/deleted/corrupted .. well you get the idea ... these files.

I have 5 different files with multitudes of scripts, calculations and fields. One file which tends to want to crash things from time to time.

This last time I hadn't backed up my changes yet (always adjusting things) and I've had it.

SSSssssssooooooooo since my structure was below novice to begin with it's time to fix it!!

I would appreciate ANY input on the subject:

'If I could start over this time I'd....'

Thanks in advance !!

PS. I'm now up to v11 if it doesn't show........

[bcooney]

Not sure what input you're seeking; what we think are "best practices?"

[Russell Barlow]

There is some good information on developer standards at filemakerstandards.org.

[Vaughan]

If you have the luxury of time, I'd do this:

1) Convert the existing system from .fp5 to .fp7 if not already done. Do the minimum amount of development to get the system running again. Do not fix existing bugs or introduce new functionality.

2) Start building a new system from scratch. Copy and paste table and field names to make data transfer between the old and new systems easier. (If necessary rename tables and fields in the old system if they have illegal characters in them.) During the build, create scripts to automate the process of importing the data from the old system into the new system, performing whatever conversions and data cleanup is necessary. You should be able to make a clone of the new system and run a script, get a coffee and come back to find all the data from the old system is loaded and ready. (Don't underestimate the amount of work in this step, but also realise its value.) Each time you run the update routines you'll find problems: fix them and if necessary clean up the data in the old system. Run this import process every day. After a couple of weeks the import routine will be sweet-as and the data in the old system will be in significantly better shape.

3) When the new system has sufficient functionality, de-commission the old system and transition to the new. This will be easy because you can train people on the new system for a couple of days, then run the import routine and have it ready next morning. Use this period of dual-systems to do user testing and get it easy to use, then people will want to change to it. Don't wait for the new system to be complete: get it into production as soon as possible with the minimum features to make it function today. Prioritise the remaining work and do it as the business needs require. For instance, the reporting might be mission critical but not needed for 3 months, so instead do something else that's needed next week.

I did this for a client last year and both the development and the implementation went very, very smoothly.

[Cabinetman]

I've been reading over the standards and pretty much knew this stuff anyway.

To answer bcooney .....

Basically what FM may have left out o more importantly something that you found that works better.

i. e...... I keep a separate .txt file on every calc. I write so I can copy/paste them quickly

or ... I have a separate .fmp with all my variables to load at startup for easy import into new solutions

And thanks Russell and Vaughan (PS - already .fp7)