Jump to content

Best Practice: Multiple Developers for Single Solution


This topic is 5222 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I would like to know if anyone can give me the pros and cons of having a solution that is maintained by more than one person.

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.

Link to comment
Share on other sites

Pros: Less work for you to do. They can do some of the more simple but tedious work.

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.

Link to comment
Share on other sites

Thanks for the input Fenton.

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.

Link to comment
Share on other sites

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!!

Link to comment
Share on other sites

This would appear to be a recipe for disaster, especially if there is any complexity to the program. However, that being said, sometimes orders come from above and one must make do.

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

____contacts

____Orders

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

Link to comment
Share on other sites

If a beginner has Full Access to Manage Database of a complex solution, it is like giving an infant a colorful plastic bag to play with while you go make dinner. At (very) best they will add fields you don't know about, hence will not add to automated routines. The worst has so many possibilities.

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.

Link to comment
Share on other sites

Sorry for the slow response. I am not at work today. I do have one glimmer of light in my corner which is my immediate supervisor. He is in agreement that this is not in the best interest of our database or our company. We just have to sell that to the owners. I appreciate the information from each of you. I'm compiling my "this is why we shouldn't do this" speech.

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.

Link to comment
Share on other sites

It is ironic that I should be writing about this earlier today. Then later on I was troubleshooting one of the most critical scripts in a solution I built, which is now in production. It was for processing charges via credit cards (using the Plastic plug-in). The on-site developer, who is a smart guy, and has been learning FileMaker over the months we've been working together, had been asked to add a routine to send an email to various people when any transaction took place. He wrote it into a subscript, and called it from my (long) processing control script. That is fine, as far as it goes.

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.

Link to comment
Share on other sites

To Fenton:

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.

To Dana;

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.

Link to comment
Share on other sites

Anouther consideration may also be security. I am not sure what your situation is but, I know that many of the employee's here are paid based on what filemaker reports. Anyone paid off of information within filemaker should NEVER be given the ability to develop in those files. If they had it and any skill at all, the potential exists for them to systematicly padd thier own paychecks.

:twocents:

Link to comment
Share on other sites

This topic is 5222 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.