Large Solutions

[FMDuck]

I typically develop what would probably be considered small business Management Systems that handle everything from prospecting to payment receipt, etc. The solutions are always fully locked down and are very granular and feature rich. Typically about 50+ tables, 200+ layouts, 2000+ fields, etc.

Solutions typically include hundreds of variable situations where one user group's transactions are controlled one way where another groups transactions are controlled differently unless management sets a switch because management is out of the office, etc. This is just one very small example.

My problem and question is that as FM adds new features, I find it increasingly difficult to use those features because of the time and cost of testing. For example, I find FM's security impossible to user beyond basic privilege sets. Also, adding a script trigger to a field then copying it 20 times resulting in the user getting locked down then can't continue. This is just one a great number of examples (which, in a vacuum is easy to avoid - but compounds as the solution grows) I am increasingly apologizing for never-ending bugs that simply seem to go from one place to another, while trying to balance my customer(s) development costs against an acceptable amount of bugs.

I would love to hear from others that have developed larger solutions and get some insight into how you develop large solutions in contrast to small ones.

Thanks much.

[IdealData]

You are not alone Jeff - I suffer the same way too.

You have to develop using the tools that you know work, so you only ever use the features that you love and trust - otherwise bug testing becomes painful, costly and embarrassing.

I often phase develop my solutions, getting my client to do testing along the way. It helps to get things signed off and paid too. This gets early attention from the client and sustains their interest in the development and opens up doors for 'extras'.

HTH

[FMDuck]

Thanks,

One of my problems is that I can never seem to get customers to test anything. Part of my problem may be customer's expectation. Most solutions I develop take about 1 to 2 years but most customers expect them to be about 1/10th the actual cost and never want to test. One time I even had to deal with every user individually.

I am often left feeling one step over lawyers and user car dealers. I never feel like I can exceed the customer's expectation so there has to be something I'm missing. I don't know if FM is simply the wrong tool for what I'm doing or maybe I'm putting myself into a space where the customer's and the tools (FM) don't match up.

I'm sure that I'm not the only one in this situation though and it seems like there has to be a way to improve the situation.

Thanks again.

[BruceJ]

I create what would be considered large solutions as well. Mine are medical/hospital systems and keep growing and growing as users want more and more functions.

I could never take one of those gigantic solutions and change it around just to take advantage of a new feature that FMP came up with. I just leave it in it's original version. I have about 6 hospitals running on Sever 5.5 though I have every evolution of newer versions of developer and server available.

I have another client who is still using version 3 that I made for them many, many years ago. It's a testament to the software that the application continues to meet their needs and still runs like a charm... even in those old days when there were so many work arounds.

It's tough though switching back and forth between the concepts of version 3 to version 6 and for the past couple of years I've been creating new solutions in version 8. I'd love the script triggering and all but I was able to work without this for many years, so I'll just continue to work without it.

[JerrySalem]

Jeff,

No one mentioned it yet, so I am obligated to mention it.

DOCUMENTATION.

I know it is often forgotten and not updated. But for large solutions it is essential you write down changes, decisions and End User Work Flows.

This will help when you need to add new features from one version to the next.

Of course run the DDR and study it. Often.

Finally, when implementing a new feature Have A Plan.

For example; custom formatting a field with bad data to appear in Red.

Decide what fields need this feature.

Is there an exiting work around that needs to be removed/modified.

Use the DDR to identify where the End User may see these fields.

Write down in your documentation about the change and why it was made.

Finally, If I have an existing work-around I need to think long and hard about spending my clients money to remove a feature (that they already paid for) and pay to install it again using a built in feature/function. (in this admit-ably simple example, there is very little end user benefit to removing calculation fields to show bad data in red and replace it with custom formatting)

I usually save new filemaker features for new requests in a solution.

That is my $0.02

Jerry

[FMDuck]

I think a question that comes into play is the TCO of a large scale FM solution compared to other platforms and it's the other platforms that I don't know about. FM adds many features that are difficult to find. Constantly running and analyzing DDRs is time consuming in itself if for a small change.

A good example is how simply duplicating a field can make a mess. You can't readily see the details of Conditional Formatting, Tooltips, 'hiding-and-sliding', script parameters, etc. This was annoying but never a real serious problem. Now FMI has added Script Triggers and they're not readily apparent either. By this I mean that although you can tell that some of the settings exist, you can't tell what they are. With Script Triggers, a FMP user, in contrast to an FMPA user can get stuck in a real predicament if you're not real careful. I think an inspector panel for layout objects is WAY overdue. I started harping about one at FM5 and it still hasn't happened. This one feature would change a lot, but without it, I feel like much of the development either requires an extraordinary amount of time compared to what an FM customer expects or you have to put up with bugs and let the customer find them.