1 of 1 people found this helpful
Well, you already hit on one important idea: Comment. comment, and comment some more. (Few of us, if we're honest, do it enough.) Because the next person who comes along won't know what the heck you were doing if you don't. (And that includes when the next person is you.)
You also are on the right track with a good naming convention. The specific convention you use is less important than having one and sticking to it.
Other ideas include more flexible design. For example, don't duplicate a layout and change one field to make a purpose-specific report. (Sounds like you have a lot of that.) Instead, make a single report serve multiple functions through the use of merge variables, global fields, the Virtual List technique, different subsummaries, and any other technique you can think of so that you can repurpose the same layout in different ways. Scripting can be the same; don't write 15 scripts that are 95% the same. Instead, write 1 script that performs that function and pass parameters to adjust its workings as you need.
You can also make use of tools like BaseElements and Inspector Pro. These Database Design Report analysis tools allow you to identify abandoned elements, unreferenced objects, and the like, which will help you know what's safe to delete. (Of course, it won't tell you what the users aren't using any more, but at least you can identify what the system isn't using.)
1 of 1 people found this helpful
Big question =)
Here is what's helped us....
1. Use a bug tracking database, not in FileMaker, and use it for feature requests also.
- We use FogBugz, but consider Jira, ZenDesk, etc.
- All these will let people submit bugs/features by email: add a button to send such an email to every layout of your solution.
- These apps lets you sort, prioritize and discuss changes while keeping a record of the reasons behind your features & fixes.
2. Use a version number in your FileMaker solution.
- This can be as simple as an unstored calc in one table that you increment each time you mod the softwrae.
These two things combine toward something pretty cool:
3. When you make anything new, comment it with the currrent version number of the softwrae (from no.2 above), and the bug case # (from no.1 above) so you know why you did it.
- In scripts, this goes in the header of the script or in comments around the individual steps. In layouts this goes off to the right in the "offscreen" part of the layout.
- By including the case #, you're a quick search away from the original bug / request that motivated this.
- In the screenshot below, 6.25 is the version of our app, followed by two FogBugz case numbers.
- Should you break something you can use The Tool to find all the scripts that were modified as part of a particular case # or modified in a paricular version number of your softwrae.
Hope that helps,
FileMaker Templates & Calendars
This will always be a problem, with a mature solution, especially when you allow your users Full Access
Folders help greatly to store the leftovers
I try not to delete anything, since you're often not sure, just rename them as OLD or VOID
> But what about "Kristen's Layout?" She hasn't worked here in years... does anyone even use that layout?
A problem to be sure, and one I've faced with numerous clients.
I don't believe that there's really any good way to manage something that has become cognizant. With all of the changes over the years/developers/tools, I would recommend that you're better off designing a new solution that meets your current needs and processes, build from scratch, and leverage the ideas listed above. This way your free of the baggage and potentially disruptive code that would only further hamper you later.
My two cents.
+1 to many of the comments here, especially bug tracking, versioning and commenting. I just wanted to throw out this as well:
If you do versioned releases, tools like Inspector Pro let you run Diff reports on DDRs, so you can identify EXACTLY what's changed between V1.0 and V1.1, for example. This can be helpful post-release if any bugs crop up - you can identify if the bug is a result of coding changes in the 1.1 release, and what code may be the culprit.
P.S. Also helpful for those clients that like a complete report of what has changed from a coding perspective (rather than feature descriptions).
+1 for Inspector Pro. I use it nearly every day. Makes my life so much eaiser.
To tell if users are accessing certain parts of the system, you could put in an "audit log" table of speaks. Have it fire on those odd layouts to capture who is accessing them and how often.
After a month (or whatever time period you decide) you can look at your audit log table to see the results. If these random old layouts aren't being accessed at all by users, you're most likely safe to remove them. Of course, this would be in combination with an Inspector Pro analysis to make sure these layouts aren't critical to a script, calc, value list and so on.
Just an idea.
Another tool that I use is a Script Log as described by Ray Cologon in his FMP Bible for FileMaker 10.
The code that's placed at the start and end of each script is quite short and easily replicated for each script. It can even be used for logging script errors.
It does not need to be on every single script, just the ones you want to monitor.
In our case I was able to question a contractor's invoice for time spent on the job, based on her not running an Opening Script on that day when she did it routinely every other day. That was NOT my original reason for starting the Script Log!!
I fully endorse both Inspector and log tables, but I also need to ask so what if there's a Kristen's Layout? If you've got a solution with 100 extra layouts, it still doesn't affect performance. FileMaker doesn't really care if it's messy. My recommendation is, if it works, don't screw with it.
My recommendation is, if it works, don't screw with it.
ditto. Why strip functionality?
We all know that Kristen will walk back through the door within days of you deleting that layout.
… so what if there's a Kristen's Layout? If you've got a solution with 100 extra layouts, it still doesn't affect performance. FileMaker doesn't really care if it's messy.
There may not be a performance hit from FileMaker, and FileMaker may not care, but there is a definite performance hit for "the next person." As Mike hit the nail on the head:
(And that includes when the next person is you.)
If you aren't going to delete, at least put stuff that you think may be obsolete in a folder together. You'll thank yourself. The less you have to wade through, to understand what is going on, the easier you can get to work.
Just my $.02.
I tend to agree. I’ve inherited more of these legacy systems than I care to think about, and they’re even confusing for users. (“Home grown” developers often are less than diligent about cleaning up the Layout menu.) However, it’s frequently difficult to know exactly what layouts users do utilize.
So, like Shawn, I find a good solution to be a “deprecated” folder. Stick the layout in there (hidden from the users) for some period of time. If no one squeals, it’s probably safe to delete.
< Instead, make a single report serve multiple functions through the use of merge variables, global fields, the Virtual List technique, different subsummaries, and any other technique you can think of so that you can repurpose the same layout in different ways.>
Mmm, I went down this path for a while because it was 'logical' however I've now undone a lot of this, for two reasons. One, the 'intellectual' maintenance (after a break and many other systems, even with commenting) is just too time-consuming. Tautology can be surprisingly time-efficient. Two, 'copy and paste' works brilliantly, plus additional comments to draw attention to the differences. Yeah, if it's only a very minor difference then maybe not a separate layout, but make each call depending on the circumstances.
Haven't used Inspector Pro so can't comment on that but I have used - and highly recommend - 2EmpowerFM - it's a brilliant tool to use for rewrites.
Re cleaning out the layout clutter - for inherited systems where it seems unlikely, but 'unproveable' that layouts are being used, I've tended to add polite but intrusive notes (big!) in the centre of screen, requesting users to contact me asap if they need the note removed. If I've heard nothing for three to six months, it's probably fine to trash. (Decluttering just feels good!)
<how do you keep things current and tidy?> Tidy as you go - otherwise it'll be like a teenager's bedroom floor.
All the best,