Jump to content

  •  

Photo

Best Practice: Multiple Developers for Single Solution


  • Please log in to reply
9 replies to this topic

#1 Dana G  Always Learning

Dana G
  • Members
  • 205 posts
  • FM Application:11 Advance
  • Platform:Mac OS X Snow Leopard
  • Skill Level:Intermediate
  • Membership:TechNet
  • Time Online: 6h 15m 28s

Posted 03 December 2009 - 07:09 AM

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.
  • 0
Thanks,
Dana

#2 Fenton  Post Master General

Fenton
  • Moderators
  • 5,046 posts
  • FM Application:11 Advance
  • Platform:Mac OS X Snow Leopard
  • Skill Level:Expert
  • Membership:TechNet, FileMaker Business Alliance
  • Time Online: 17h 6m 25s

Posted 03 December 2009 - 08:51 AM

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.
  • 0

#3 Dana G  Always Learning

Dana G
  • Members
  • 205 posts
  • FM Application:11 Advance
  • Platform:Mac OS X Snow Leopard
  • Skill Level:Intermediate
  • Membership:TechNet
  • Time Online: 6h 15m 28s

Posted 03 December 2009 - 09:08 AM

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.
  • 0
Thanks,
Dana

#4 IdealData  IdealData

IdealData
  • Members
  • 2,568 posts
  • FM Application:12 Advance
  • Platform:Mac OS X Snow Leopard
  • Time Online: 8d 9h 25m 3s

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!!
  • 0
Ideal Data - Coherent systems for a chaotic world
I'm available for hire, e-mail me

#5 David McQueen  developer

David McQueen
  • Members
  • 326 posts
  • LocationBarrie, ON, Canada
  • FM Application:11
  • Platform:Cross Platform
  • Skill Level:Expert
  • Time Online: 20h 34m 26s

Posted 04 December 2009 - 05:51 AM

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... ;-)
  • 0
David A. McQueen,
LICHEN Software,
Barrie, ON, Canada,
(705)720-9022,
www.lichen-software.com

#6 Fenton  Post Master General

Fenton
  • Moderators
  • 5,046 posts
  • FM Application:11 Advance
  • Platform:Mac OS X Snow Leopard
  • Skill Level:Expert
  • Membership:TechNet, FileMaker Business Alliance
  • Time Online: 17h 6m 25s

Posted 04 December 2009 - 09:52 AM

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.
  • 0

#7 Dana G  Always Learning

Dana G
  • Members
  • 205 posts
  • FM Application:11 Advance
  • Platform:Mac OS X Snow Leopard
  • Skill Level:Intermediate
  • Membership:TechNet
  • Time Online: 6h 15m 28s

Posted 04 December 2009 - 12:49 PM

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.
  • 0
Thanks,
Dana

#8 Fenton  Post Master General

Fenton
  • Moderators
  • 5,046 posts
  • FM Application:11 Advance
  • Platform:Mac OS X Snow Leopard
  • Skill Level:Expert
  • Membership:TechNet, FileMaker Business Alliance
  • Time Online: 17h 6m 25s

Posted 05 December 2009 - 12:30 AM

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.
  • 0

#9 David McQueen  developer

David McQueen
  • Members
  • 326 posts
  • LocationBarrie, ON, Canada
  • FM Application:11
  • Platform:Cross Platform
  • Skill Level:Expert
  • Time Online: 20h 34m 26s

Posted 05 December 2009 - 04:00 AM

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.
  • 0
David A. McQueen,
LICHEN Software,
Barrie, ON, Canada,
(705)720-9022,
www.lichen-software.com

#10 aholtzapfel  master

aholtzapfel
  • Members
  • 306 posts
  • FM Application:9 Advance
  • Time Online: 16h 10m 13s

Posted 10 December 2009 - 12:31 PM

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:
  • 0




FMForum Advertisers