Category Archives: Customer Service

Software Piracy

I was looking at a recent error report and surprised to see included in the error report a screen shot of a software pirate at work. The miscreant appears to have been trying to figure out why a crash was occurring with the license checks removed:

It’s not the first time I’ve seen such screenshots but it’s a useful reminder of how hard people work on tasks that, consciously or not, undermine the  structure of the company and the ability to support and improve the very products they, the pirates, want to use.

Continue reading

FileLocator Pro and Large Searches

FileLocator Pro Crash ReportDuring August 2012 we quietly added a new crash reporting module to FileLocator Pro. Based on CrashRpt (an open source product hosted on Google Code) it’s one of the most useful quality control features we’ve ever added, although we hope it’s a ‘feature’ most of our users will never have cause to see.

Since then you may have noticed an increase in memory management related upgrades to FileLocator Pro. It’s not a co-incidence.

We’ve had a slow trickle of crash reports over the last few months and while most were odd, quick to fix, edge-case samples the majority have been related to memory management issues. It didn’t take long to see that FileLocator Pro had a problem on low spec’d machines performing searches where the data was in the gigabyte range and involved millions of files. We found a few problems that were simply bugs in the code, e.g. algorithms that reserved more memory than was necessary, but some of the problems were more subtle function related issues.

By default FileLocator Pro will record up to 10,000 lines of text per file and each line can be up to around 20,000 characters. That’s not usually a problem when searching in a limited set of files. Rarely will a file have 10,000 hits or a line have 20,000 characters. However, when searching over a very large data set with criteria that might not be very selective (e.g. searching for the letter ‘a’ – which was the actual search phrase in one of the crash reports we received) it can be a problem. It can be compounded by searching through file types that may not have EOL (End Of Line) markers, such as EXE or DLLs. Finally to make the whole thing just a little bit trickier, what might be a problem on a scrawny 512MB laptop is not necessarily a problem on sturdy 16GB PC.

The trouble is that FileLocator Pro doesn’t know at the beginning of the search if it’ll find a few hundred files with hits on a few lines (easy), a couple of files with hits on 10,000 lines (not a problem) or a million files with each one reporting hits on 10,000 lines (problem… probably).

FileLocator Pro 6.5 introduces a pre-emptive based solution. Based on the amount of memory installed on the machine FileLocator Pro sets an upper limit for un-restricted results per search (from 20MB up to around 200MB). If during a search that limit is reached FileLocator Pro starts restricting the search. Results for each file are reduced to around 20 lines, with a maximum of 256 characters per line, and the restriction is retained until the search finishes. If the search still runs out of memory then rather than crashing, as it did previously, it terminates the search.

Our tests on very low powered machines with just 512MB have shown a huge improvement in stability for very large searches and so far we haven’t received any memory related crash reports. Job done? Not quite but it’s one more step in cementing FileLocator Pro’s place as the ultimate super fast, rock solid, search and data analysis tool.

In a previous post I talked about ‘pushing a button that I think does nothing’. I hope you can see from our response to these bug reports that when you ‘Push the Button’ and send us a crash report it most certainly does something!

Customer Service

One of the few areas a smaller software company can compete with large software companies, like the Microsofts or IBMs of this world, is customer service.

Our customer service queries are answered either by me personally or by a software developer who can review the actual source code. It pays for us to have software developers answering questions but not just for customer satisfaction. Customers are, more often than not, helping us to make our products better. It’s amazing. They’re spending their time making our product better and then they thank US at the end of it. Simply because we’ve listened to them.

We never forget that we’re the main beneficiary of the correspondence. Who knows how many other people couldn’t be bothered to tell us about the issue/feature deficiency and simply uninstalled the product? As a rule of thumb I put it at around 1 in 100 will contact us, which highlights just how special each correspondence is.

However, there are a rare few people who can create problems and waste time. Suddenly customer support can become quite a challenge. Fortunately we only have one or two challenging users but I thought it’d be interesting to show you the correspondence with one of those users over the past decade to illustrate the harder side of customer service.

Continue reading