8 Replies Latest reply on Mar 18, 2013 10:27 AM by MattLeach

    Support issues for in-house developer

    Gingernut

      I work for an office equipment company and have written the system that all our Franchises use to run the business from Purchase Orders , service call logging to invoicing and stock control.

       

      I was talking to one of the users of the system over the weekend and she expressed concern that all the offices are using my system and I am the only person who supports it.

       

      On reflection I can see this could be an issue and I am re-writing it in Filemaker 12 (has evolved since Filemaker 7 and is a mish mash at the moment)

       

      I am trying to put a lot more information in the scripts and make things a lot easier to follow but wonder how other companies resolve these concerns.

       

      I know any other developer could eventually unravel my solution but was also wondering how other small companies manage with only one developer.

       

      Would be interested in people's thoughts on the best way forward although to be fair the system has been in use for many years and I do take holidays with no issues arising.

       

      Regards

       

      Cathy

        • 1. Re: Support issues for in-house developer
          MattLeach

          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.

          • 2. Re: Support issues for in-house developer
            deninger

            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.

            • 3. Re: Support issues for in-house developer
              Gingernut

              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.

              • 4. Re: Support issues for in-house developer
                GordonShewach

                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.

                 

                Gordon Shewach

                Desktop Services

                Ann Arbor, MI

                • 5. Re: Support issues for in-house developer
                  MattLeach

                  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.

                  • 6. Re: Support issues for in-house developer
                    wimdecorte

                    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).

                    • 7. Re: Support issues for in-house developer
                      Gingernut

                      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.

                      Cathy

                      • 8. Re: Support issues for in-house developer
                        MattLeach

                        I just use a standard Word Document but have it formatted with a table of contents for ease of use.