13 Replies Latest reply on Feb 2, 2014 9:51 PM by mardikennedy

    taming the feature creep

    user14967

      A local road-side attaction shop in my hometown has what they call "The Creep Closet." Against all posted warnings and advisories to not look in the creep closet, fully 100% of visitors peer in to witness inescapable horror.

       

      Likewise, over the years, my own creep closet, our company's FileMaker Pro database, has become a repository for sloppy coding and layout design. As I prepare to finally make the jump to FMP13 (from FMP6!), I am being forced to reckon with my own past. Copies and copies of test layouts that are never used... those are easy to identify. But what about "Kristen's Layout?" She hasn't worked here in years... does anyone even use that layout? And the script... "Transfer print specs to PO." Pretty sure we gave up on that back in 2003. "Time Report for ACME Widgets?" Well, we lost that account five years ago. But maybe someone still uses it for another purpose. If so, how do they even access it?! And all those poorly-named global and calculation fields: surely I didn't create them. Has Filemaker become self aware? Am I witnessing the singularity at my very own workstation?

       

      Moving forward, I wonder what advice more seasoned developers might have to prevent these kinds of questions in 2023? FMP13 certainly seems to have better commenting features than what I'm used to. And I know I should keep up with my naming convention, even for quick requests for a new report. But after years of turnover, changes in business policies, and client loss/gain, how do you keep things current and tidy?

        • 1. Re: taming the feature creep
          Mike_Mitchell

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

           

          HTH

           

          Mike

          1 of 1 people found this helpful
          • 2. Re: taming the feature creep
            JohnSindelar

            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.

             

            CaseNumbers.png

             

            Hope that helps,

             

            John

             

            John Sindelar

            CEO, SeedCode

            FileMaker Templates & Calendars

            http://www.seedcode.com

            855-SEEDCODE

            1 of 1 people found this helpful
            • 3. Re: taming the feature creep
              gdurniak

              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

               

              greg

               

               

              > But what about "Kristen's Layout?" She hasn't worked here in years... does anyone even use that layout?

              • 4. Re: taming the feature creep
                techt

                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.

                 

                TT

                • 5. Re: taming the feature creep
                  ColinKeefe

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

                  • 6. Re: taming the feature creep
                    Ethan.Shoshin

                    +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.

                     

                    Ethan

                    • 7. Re: taming the feature creep

                      Hi Everyone,

                       

                      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 HTH,

                       

                      John

                      • 8. Re: taming the feature creep
                        DavidJondreau

                        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.

                        • 9. Re: taming the feature creep
                          ColinKeefe

                          Sometimes it's just nice to tidy up a bit, you know?

                           

                          messy_desk_contest_winner.jpg

                          • 10. Re: taming the feature creep
                            Malcolm

                            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.

                             

                            malcolm

                            • 11. Re: taming the feature creep
                              flybynight

                              DavidJondreau wrote:

                               

                              … 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.

                              Laters,

                              -Shawn

                              • 12. Re: taming the feature creep
                                Mike_Mitchell

                                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.

                                • 13. Re: taming the feature creep
                                  mardikennedy

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

                                  Mardi