We did it! FileLocator Pro 6 is out and it’s looking great, for more information check out the 6.0 release newsletter here:
Making major changes to a product is not something to be taken lightly. Most of us have experienced the disappointment of installing a new update to a much-loved product only to find that rather than improving it the result was something bordering on useless.
I remember my personal frustration when upgrading PaintShop Pro from version 7 to 8. What had been a fast loading, easy to use, rock solid application suddenly morphed into a slumbering buggy monster. It was unceremoniously removed from my PC and thrown in the bin. It was only recently, 8 years later, that I felt brave enough to give it another go, now version X3. Sure enough many of the issues have now been resolved and it’s returned as my favourite image editing program but I still remember that sinking sense of disappointment.
We only really learn about life by experiencing it and no more so than in Customer Service. Over the last few days I’ve had a customer service experience that I’ve found very interesting. A situation in which my very negative opinion of a company was turned around to a pleasantly positive one.
How would you answer the following question:
Do software developers write software for Windows because
a) Windows is REALLY cool and hip
b) Microsoft creates a great environment in which to write applications
c) 90% of all PC users use Windows
d) Microsoft understands and looks after 3rd party software developers
e) Windows users understand that paying for software provides much needed support for their favourite tools and utilities
My answer: “f) All of the above (except a)”.
What’s my point? Well, it’s a convoluted answer to numerous, very complimentary, requests to port FileLocator Pro to the Mac. Usually I reply something along the lines of “We don’t have the resources to support multiple platforms with minimal market share”. But it’s not as simple as that.
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.
I’ve been using Windows 7 for a couple of days now and really like it. However, there was one small niggle… my ‘Command Prompt Here’ folder context menu option had disappeared.
It seems that Command Prompt Here has been added as a standard ‘Extended’ option in Windows 7 and that’s where my option had gone… onto the folder’s Extended context menu, which is visible if you hold down Shift while right-clicking on a folder. Since I use that option so often I wanted it back on the regular context menu. Fortunately this is very simple:
Go to HKCR\Directory\shell\cmd
Delete the string value ‘Extended’
And Hey Presto it’s back!
Our automated test system has discovered bugs, often just before a big release, more times than I’d care to admit. It’s an invaluable tool and one recommended by most modern development methodologies. However, I’m not a fan of methodologies in general. Let me preface that with a little bit of personal history…
Back in 1994, while working for a bank in London, I was asked to come up with a specification standard that could be given to any old ‘monkey’ and would produce reliable results. Management were fed up with the code quality and productivity disparities through-out the development teams.
Yesterday Jasenko, one of the developers here, noticed that our newest components weren’t working in ‘Safe Mode’. Since Safe Mode simply runs the component in a separate process by specifying CLSCTX_LOCAL_SERVER instead of CLSCTX_INPROC_SERVER this had us all quite confused. This used to work seamlessly. On closer inspection it appears that the default settings generated by Visual Studio 2008 are to blame.
Two extra changes are now required for out of process activation to work:
One of the first things you learn as a child, apart from how good chocolate tastes, is that if you do certain things without asking your mother first you’re going to be in trouble. Not all things but some. This is a lesson I think Windows Vista needs to learn.
What are you doing?
My development machine is just that, mine. I use it for at least 8 hours every day and, without sounding too weird, have a close affinity with it. When performing a task I have a pretty good idea how much pain the machine will be in, I can hear the hard drives working, I can see the CPU temperature increasing, I can feel the responsiveness of the machine slow. It’s all cause and effect. However, when I hear the computer working without my instruction, like a mother who’s just found her ever helpful toddler trying to put the carving knives away, I have to ask “What are you doing!?”.
I just found this while debugging an issue:
if ( isConfigured() )
if ( isAllowed() )
I can’t tell you how many times I looked at that before I saw where the problem was. My brain was so used to following styling hints to see control of flow that it didn’t notice that the actual true flow was different from the visual flow. @*&^!
As with most other kids in the 1980s I grew up programming in BASIC. Variables weren’t strongly typed they just held values. Type mismatches were reported at runtime with the ‘Type mismatch at line xx’ error. If you wanted to start running a different piece of code you could simply GOTO whatever line you wanted. BASIC was a great language to learn programming in, you were in charge and the computer did the best to keep up.
Pascal on the other hand was something quite different. Pascal didn’t just run (at least the version we used didn’t), it needed to be compiled first. Variables needed to be declared ahead of time with their type specified before you even used them! No longer could you just jump around the code, instead you had to split the program up into functions and carefully control how they interacted. I hated Pascal. I preferred 6502 assembly (with an instruction set so limited there was no multiply operator) to Pascal.