Being an in-house developer myself, i had this same discussion with my employer. Aside from commenting as much as i could in the scripts, i also maintain a development manual.
The manual is basically an overview of how the system is designed to work. It does not cover the simple stuff such as this is the first name field, enter the first name, etc... but it does go over more advanced things such as all of the calculation fields, what they are and expected results, custom menus and how to edit them, backup routines, schedules, etc... things like that.
I put all of this in binders, along with a printout of all scripts in the database. This way if anything happens to me (or my computer for that matter) everything is readily accessible.
I would add that I put extensive notes and fields in my layouts outside the visible areas (FM 12) to document things like script triggers, conditional formatting etc.
Matt - I did start to keep a folder but it is remembering to always update it when something changes that I am not very good at, but I guess just NEED to do it.
Now is a good time to start as I am doing a re-write anyway and tidying stuff up
Deninger - thats a great idea and useful way to use Filemaker 12's out of screen area. Serves as a reminder to self as well I guess.
Thanks for both tips.
I'm an independent developer with multiple clients facing the same issue when I go on vacation. I arrange to have a colleague (who I met through FileMaker networking) be my stand-in should a client have a need arise. The clients have his contact info and peace of mind. I've been doing this for about 10-15 years and the stand-in rarely gets called. But everyone is more comfortable knowing that there are options if an emergency arises while I'm on a beach sans cell.
Ann Arbor, MI
I had the same problem so what i did was setup a monthly reminder in my calendar to remind me to update all documentation in my binder.
Some times it is hard to remember what was done if a lot was done in a specific month. If i make any changes to the data structure or layouts i usually document them while working on it.
When editing scripts, i dont always document right away in the manual but i always put comments in with the date of the change/addition. Using the 2empowerFM Developer Assistant i am able to search all scripts that have an entry for that month so i can re-print just those that changed and add to my manual.
So far this has worked pretty well and has helped me develop a routine. I usually have everything updated before my reminder pops-up.
Probably the most important thing is documentation:
- if you have a set of development standards, document that. If you don't pick one of the standards that are out there and follow it rigoursly (and indicate which one you are following)
- invest in a tool l like BaseElements and do periodic snapshots of your solution. That will document changes over time
- create a user manual and keep it up to date
Find another FM developer and invest in him getting to know the solution so that you have an established fall-back. That prevents you from being the "single-point-of-failure"
All of these cost time and money, but they are very much an integral part of the solution's cost (and value).
All sound advice - now I need to find/make the time to follow it.
What do people generally use to maintain their Manual - Just normal Word Document or a Help File?
Thanks all I am going to do a bit of all the above.
I just use a standard Word Document but have it formatted with a table of contents for ease of use.