Best Practice: Multiple Developers for Single Solution
Posted 03 December 2009 - 07:09 AM
I have built our system from the foundation up (6+ years by myself) and am now being pushed to allow additional individuals in our firm to assist me. While I like the idea of being a "supervisor" in terms of advancing my career, I have some reservations about the integrity of the database.
Any insight would be appreciated.
Post Master General
Posted 03 December 2009 - 08:51 AM
Cons: You have to fix/reorganize anything they do in a less than optimal manner. They may use a slightly different style of naming, scripting, script arrangement or modularization.
I find that it is usually much more difficult for me to understand and fix other people's scripts than my own (which are not always perfect the 1st time, for some reason -).
I think the method that works best is for one developer to be the "boss" and the others to follow their direction and conventions, at least in cases where you have more experience and skill than they. In any case everyone must use exactly the same naming conventions for both fields and table occurrences; likely even layouts.
A more subtle difference is in how they write scripts. They need to understand that it is not enough to just write a script that works. Longish scripts need to have "sections" of operations, separated by (blank) comments, with explicit comments where needed (but not where not needed).* Likely comments for a creation date & person, and possibly a modification date and person need to be added.
*One of the problems of beginners is that they tend to either write no comments at all, in either fields or scripts; or the opposite, write comments for dead obvious things, which just clogs things up.
Posted 03 December 2009 - 09:08 AM
Another problem I have is that these people who will potentially be assigned to help have absolutely no experience and will continue to do their regualar jobs. That combination is not too thrilling to me. I'm at a point where I want to say "What's the point in teaching them anything?". They need to develop on a constant basis to keep their skills up.
Posted 04 December 2009 - 01:28 AM
potentially be assigned to help have absolutely no experience and will continue to do their regualar jobs
How can they help if they have no experience? Where will they get the time to do the development? Sounds like the "assistants" are being appointed by authorities that don't understand what FM development is like either.
If you have 6+ years in this system then it is likely quite large and will need considerable experience to grasp your methods and designs.
Shouldn't your "assistants" come with some qualifications?
Keep a backup available at all times!!
I'm available for hire, e-mail me
Posted 04 December 2009 - 05:51 AM
1. Go back in and arrange all of your scripts, layouts etc. in some sort of order and make some "dummy scripts" and "dummy layouts" with names like
or use folders for scripts
So that the location of scripts and layouts is arranged by program functionality. Then you can assign areas of the program if necessary as time goes on.
2. Decide just what you are going to let these people do. This will be a moving target as they actually learn things. Example: See this button "Relationships" - don't touch that.
3. Find out now if you have authority to remove people for this "duty". I have always had a rule that I will not take responsibility without some sort of matching authority.
4. Take a hard look at your relationship graph. Do you have an all seeing all reaching spider or have you got it modularized.
IE: If they break something there are you into things breaking all over the place or are you into fixing a single subsystem?
5. Training - Are they going to provide your people any? Are you a supervisor, or are you chief cook and bottle washer and teacher of filemaker also + your "real job".
And as someone else mentioned lots and lots of backups.
Random thought here. I think that your hard work and diligence has scared the hell out of someone higher up. This looks like a knee jerk reaction to the thought " If he leaves we are so scr*&ed".
Second random thought. A really good raise might be in order here. Just saying... ;-)
Barrie, ON, Canada,
Post Master General
Posted 04 December 2009 - 09:52 AM
One automated routine you will need almost immediately (actually you need it anyway), is an "import all data, all tables into clean clone, update serials ids" script.
There is also a way to limit access to only some scripts and some layouts. From my way thinking access to particular Layouts is the only place where it makes sense to allow a beginner access to modification. They can also have "new layout" access. This way they can do things like add PDF forms. But even then there is very little they can do. Because "flat" forms often require some knowledge of relational structure to add fields. Printing is another area where what may look simple to someone with no experience is often difficult, even for a developer; calculations for display, sliding/printing, etc..
If the company really wants "someone else to learn this", then you can create a set of dummy files, single user, no sharing, renamed with Advanced. Let them learn on that. And/or, let them watch while you work on real files via screen sharing. But, as David implies, this is going to eat up a fair amount of your time.
I do not really know that there is any easy answer to the problem of how to pass on maintenance to even another developer, much less a beginner. I have been on the receiving end of such a hand over, and it was not easy, though I got up to speed in time. In that case, the previous developer had very good structure, excellent anchor-buoy organization of the Relationship Graph, intelligent scripting, etc.. Other times I have had to rewrite some (much) of the previous person's structure and scripts.
It would be a good time for you to look hard at how you have organized the file, pretending you are another person, and see what you could do to make it more understandable, and easier to modify later. It would be beneficial for yourself as well. Let management know that you are doing this, whether they assign others or not. It is by far the most efficient way to improve a solution.
Posted 04 December 2009 - 12:49 PM
In response to David...yes I need a BIG raise. I started as a receptionist/package shipper 11 years ago. A little over 6 years ago this opportunity just fell in my lap. I have no idea what a FileMaker developer's salary is. Closest I can find is a database administrator on salary.com that seems to match pretty well. If that's the case I make approx 60% of what I should. Problem is that most of FileMaker comes very easy to me. I have to find a way to get across that just becuase it's easy doesn't mean that I or my work has less value to the company. Anyway - that's a separate discussion. Lucky for them I love what I do and where I do it.
I also don't think that our owners know what is involved. They are architects and are just glad "someone takes care of that". I think that they have a very limited knowledge of what I do. That alone is most likely the reason for this "strategic planning", "disaster recovery" or whatever you want to call it.
Post Master General
Posted 05 December 2009 - 12:30 AM
They did not tell me about it. As far as the scripting, he did OK, actually very well, using Variables, etc., but for omitting one step, Go to Layout [ the layout where the script had been before he went off to an Employees table to gather email addresses ].
Because he neglected to return to the processing table, some subsequent steps to set fields in the Invoice (like fully paid) were wrong, though no errors were thrown up. Because the steps no longer had access to the payment or invoice items data, and 0=0, all Invoices were marked fully paid, no matter what the balance remaining. We were lucky that this was about the last thing in the script.
That is the kind of thing (or worse) which is going to happen if people who are not experienced FileMaker developers write scripts, without close supervision. We've all made this mistake, so this is not a judgement. But I learned, and seldom make it anymore; in any case I always run these kinds of scripts via Script Debugger first, test the results, etc.. A wrong layout context is pretty easy to catch that way.
We were lucky. It was not that hard to either fix or reset the data. But it could have been much worse.
Posted 05 December 2009 - 04:00 AM
That sounds like "Too Much Fun". I remember having a discussion with my son. He is project manager in a brutally fast paced environment and very young at it. He was pretty tired after a particulary rough stint. I told him that it was too bad that he wasn't just a bit older, not because he would be smarter, but he would already have made more mistakes so he would not have had to backtrack on anything.
Essentially that is one of the differences between the onsite developers and the "helpers" as the on site developer knows the program and has already made many mistakes. It is also the difference between the professional developer and the on site developer. Having been on many many jobs gives you that many more mistakes under your belt.
It think you will find that the people who do this fall into two camps, though there is intersection. There are those from a formal programming background where filemaker is a tool of choice, one among many. The other side are those that come from a particular busienss background who in one way or another became charged with "Doing Something" and found that FileMaker thinks like they do. The fact that the two camps exist and a historic legacy of FileMaker advertising the Legendary Ease Of Use is not helping you. In your position I am guessing that the people at the top consider what they do truly creative while everyone around them is pretty much support, doing a workman like job.Your supervisor who has direct involvement knows differently.
The analagy that they may understand is:
FileMaker Pro is like playing guitar. Anyone can do it badly but there are not that many who can do it well. Those who do it badly also tend to be those that scratch the guitar, bend the neck and break the strings.
Carrying the analagy on, if their system is in effect a $50.00 Sears guitar for hobby use, it is probably Ok to take it to drinking parties on the beach. If on the other hand, this thing is effectively a jouneyman's instrument, highly integral to making a living as a mucician,it is probably best to treat it with the respect that such a tool commands. Properly respected, it serves not for years, but with the appropriate work for decades.
Barrie, ON, Canada,
Posted 10 December 2009 - 12:31 PM