Monthly Archives: January 2014

Working with Software Support

I write software and over my IT career I’ve been on both sides of software support: needing support for an issue and providing support to customers for a software product. Getting support for potentially complex problems with complex software that you’ve heavily configured can be a challenge. Here are some ways to make the process easier for people on both sides of the support system.

What’s Wrong?

Most support starts off with the customer describing some issue they’re having in text and sending it off to the support organization. This might be an email alias like or a web form in a support portal. The point is it usually starts off with text, which is a really rough way to describe a detailed problem.

Where do you start? Here’s the standard initial points you need to address first:

  1. What did you do? Give the minimum number of steps to reproduce what you’re going to mention in 3.
  2. What did you expect to happen?
  3. What happened?

This covers the basics, helps you focus the issue on exactly what’s wrong, and allows the support person to start to focus on “our software doesn’t do that” or “yeah, that’s not right”. If the software has a GUI, screenshots can provide a lot of information easily.

After the basics, you may want to add some more detail about the issue. If you’ve seen advice that you should hire developers who have excellent writing skills, writing bug reports for support is one of the reasons. Whether you’re filing a bug report for another developer on your team or sending off a support request, you need good writing skills to accurately and concisely describe a complex issue.


If you want to avoid a guaranteed back-and-forth at the beginning, you should also provide as much of your environment information as possible up front. This includes the version of the software you’re running, including any updates or patches. Provide the system it’s running on, whether it’s RedHat Enterprise Linux 6 or Mac OS X 10.7.5 Lion.

Then include any other relevant diagnostic information. If the software has a configuration page, send along a copy or screenshot. If it has logs that you’re aware of, send along a relevant section gathered as you demonstrated the error. You may not see anything useful there, but even the absence of messages can be helpful for the support person.

Provide background on any history if there is one. You may have had similar issues in the past and support gave you a patch or update. Support may have provided steps to fix something similar previously, but the fix isn’t working this time. Provide support ticket numbers if you have them just in case the new support person couldn’t find them.

You don’t want to overwhelm the support person, but lastly you can include what you’ve tried so far. You may still get the standard “try this” response, but if you get a human on the first try, you might get bumped up to an engineer if you’ve already hit all of the obvious first steps (clear your cache, reboot, apply the latest system updates, etc.).

Following Directions

You’re probably working really hard to fix the issue on your own, which is why I suggest telling support everything you’ve tried. But once you send off the support request, it’s time to stop trying things randomly on your own. The support person is going to try to reproduce your issue and it can become very difficult if you become a moving target. In the best case, you’ll fix your issue but you won’t quite know why, which means it could happen again. In the worse case, you’ll cause another issue and then you’re really in a bind because you can’t easily answer 1, 2, and 3 from above because you were “just trying things.”

Assuming you have a decent support company and your boss has paid for a reasonable SLA, you should get a response in a reasonable amount of time. Unless it’s a really common issue, they are likely to send some instructions that will either give them some additional information or potentially solve the problem.

Do what they ask.

One of the more puzzling things I’ve encountered is the frequency with which support customers ask for help, then do everything but what you suggest. The support person is trying to piece together your problem from only a few clues and when they ask for something, they probably have an idea what’s wrong. They may be trying to rule out a known bug or confirm a particular setting or detail. When you do what they ask, you help them move along their train of thought. When you try a bunch of other things, they essentially need to reset and start again with how your system is set up now.

The Whole Story

You’re sitting there waiting for a response, your boss is bugging you every 15 minutes for an update, and I’m saying don’t try things. It’s understandable if you get a little antsy, especially if you get an idea after dwelling on the problem for a few hours or days. If you do make changes, keep track of exactly what you’ve done and let the support person know on the next exchange. Yeah, maybe you did something you shouldn’t have. Keeping it a secret just compounds the mistake.

Likewise, if you’ve been gathering information from other people on the issue, send along new information as you learn it. This is especially important if you track something down and find out you got incorrect information previously. Support may be holding off on sending you a fix because it doesn’t make sense given that part of the puzzle.


If you’re lucky, you’ll get a good support person and they’ll get you a fix. It might be a patch or update, a configuration change, or a reboot. Whatever the case, when the issue is resolved and you’re back up and running, reply back so the support person can close the ticket. Some support organizations are evaluated based on closing tickets. Knowing you’re all set helps them keep their ticket system cleaned up. Some systems auto-close after a period of inactivity, but the ticket history won’t reflect whether you got things fixed, especially if the last response included several things for you to try.

We all rely on software and it can be panic-inducing when it becomes uncooperative. Having good support available is one safety measure. Knowing how to work with them effectively is another.

Setting Up a Blog

Seth Godin‘s advice for people is to blog everyday. He doesn’t understand why everyone doesn’t do it. Well, I’m finally taking his advice and I think I can offer some insight into what stands in the way.

First Steps

I’ve always thought it would be a good idea to blog, but after attending a Seth Godin talk where he repeated his blogging advice, I decided to finally get going. But where to start?

I write software for a living, so of course my first thought is to set up something self-hosted because, you know, I might want to hack on the source. Being mostly a Perl guy, I started searching for something in Perl and found Movable Type is still a leading blog platform. I found the community site and the project on github. As I read more, however, I ran across the blog posts about license changes and found them all very confusing. Looking at the github project, I couldn’t find any clear software license referenced in the README. When I found the license purchase options, the minimum is a 5-user license, so it seems they are now focused on business users and not individual bloggers.

After spending a few days reading about all of this I realized I was allowing myself to get distracted from the main goal, setting up a blog. Did I really need to hack on the source? Of course not, the goal is to get up a blog post somewhere.

Hosted Blogs

The shortest path is a hosted blog service. There are a wide array of free and fee-based services. I read David Pogue occasionally, and noticed he recently started blogging on Tumblr. I thought this was interesting for someone who essentially writes for a living, then I realized this was likely because of his move to Yahoo from the New York Times (Yahoo bought Tumblr last year).

The conventional wisdom regarding free services is that if you’re not paying for the product, you are the product. As agreements go, Tumblr’s agreement appears to be one of the better ones, with subscribers retaining rights over their content. But I was still wanted to avoid being someone’s product.

Seth Godin’s blog is on Typepad and I also use their platform for our work blog. Having a service that is 100% managed, including updates and managing security is attractive. Starting at $9 per month, and $15 per month for the “Unlimited” plan, it seemed a little much just to get something going. I also find their interface a little pushy with the “related story” suggestions.

Around this time I also caught up on some podcasts and came across an episode of InBeta discussing blogs and blogging platforms. Sadly, hearing about all of the new options out there made me even more unsure what to choose to get my blog going. Kevin Purdy’s multi-step system has the advantage of being freely hosted via github’s hosted pages, but it seemed like a fair bit of work to get something posted. The last thing I need is more barriers to getting this thing going.

Then I realized this was all another distraction. The goal is to get a blog post up!

Hosting Service

I already had some domains registered with Pair Networks via PairNIC and Pair also does hosting. Maybe that was my next stop? I looked at the hosting plans, briefly circling back to installing one of the open source products myself. Worrying I was headed down another path of fiddling with an install, I was happy to find their software installation manager.

Most of the major hosting services have these sorts of service panels now to make it easy to install open source products. Since the products are open source, the licenses are usually clear. Using the installation managers also means you don’t have to worry about running into dependency problems on the hosting platform. They have sorted all of that out.

Pair supports Movable Type in their install service, meaning I could still work with a Perl-based platform and avoid getting bogged down in the install. There’s a fair bit on the web comparing Moveable Type to the other leading blogging platform, WordPress. Most say they are generally comparable feature-wise. I revisited the Movable Type licensing terms and still couldn’t figure out what the terms really are for the open source install. Fearing some strange licensing issues when my blog becomes wildly popular, I decided on WordPress. The other factor is the number of themes. WordPress seems to have a million out there, both free and paid.

Getting all of this out of the way, I was able to register a domain with PairNIC and set up a year with Pair hosting plus software installation manager for about $120 for the year, which is comparable to the TypePad rates. The installation manager worked great, allowing me to first install Movable Type, uninstall when I changed my mind, and then install Word Press. Since I had registered my domain with Pair, it was easy to launch the blog on my domain.


Getting this blog actually launched was amazingly easy once I finally sorted through all the options and figured out what I actually wanted to do. It’s true that having so many options is liberating, but also paralyzing. For now I’m happy with the outcome and I’m 100% in control. Now I just need to think about the theme, the layout, and topics for blog posts, but all of the distractions around those are for another post.