After participating on Pause[x]London 2011 and Pause[x]Berlin 2013 I got invited to attend Pause On Error Portland 2014 as well. Even though my schedule did not allow me to attend in person, I managed to host one session about Efficient Optimizing and Troubleshooting of FileMaker Solutions and Business Processes remotely over Skype. Now, few years later, the content seems to be still very relevant…
So, whether you could not attend Pause On Error 2014, or if you attended but want to recall some specific details, now you can watch the recording of my session here, or at least read a brief summary of the most important points below.
Just like my few previous conference sessions, I wanted to share my experience with optimizations. As part of it I also talked about the most common optimization mistakes. But one of the greatest things I discovered was that in addition to optimizations, the tool I used helped me and my team even more with troubleshooting.
A relatively unrelated case study from a New York City restaurant shows how common it is to incorrectly think that the cause of an inefficiency or bad performance is something else than what the real cause is.
When finding out why customers complained about slow service, by analyzing CCTV recordings the restaurant discovered their staff was performing still the same for 10 years, but the guests behavior changed with the rise of smartphones.
It has been proven many times that the most efficient way to optimize a FileMaker solution (or anything else) is to collect objective data, then identify the real bottleneck, optimize only that bottleneck, and then repeat the same process again.
The nice thing I discovered in 2014 is that while collecting data necessary for identifying bottlenecks, we also at the same time collect valuable data that can be used for troubleshooting. And we troubleshoot a lot more often than optimize.
Without using this collected data, troubleshooting can be very inefficient mostly because most users are only rarely able to accurately tell us what exactly they were doing prior to facing the issue we’re trying to troubleshoot.
When we have the data, however, we don’t have to rely on users because we can simply look at the log and see not only what a specific user was doing at what time, but also what other users were doing at the same time, which can help as well.
The fact that I can use the data collected by FM Bench not only for optimizations, but also for troubleshooting, was probably my most valuable discovery of the year 2014 and I was glad to be able to share it with Pause On Error attendees, so that even other people can benefit from it. So I hope sharing the recap here will help even more people.
