How Not to Promote Your Software

As part of the work I do for Developer Central, I look at a lot of software products. Sometimes, sadly, the look doesn't get far enough to turn into a review. You see, for the most part I look at new products the same way that you might: by downloading and running trial versions of the software. Sure, there are times when I'll get in touch with the marketing people and request a review copy, or when they'll get in touch with me and send one. But I still spend a lot of time cruising around the Internet, looking for new and exciting products. Along the way, I've run across some corporate behaviors that I find pretty frustrating. Here are five things that annoy me when trying out new programs:

Don't have an evaluation version at all. Some companies don't make evaluation versions available for download under any circumstances. In such cases, how am I as a consumer supposed to decide whether the product is any good? If the product costs enough that they can afford to fly out a salesman and a laptop to do a demo, this might be justified, but the average product needs to be available to potential buyers over the net. There are so many licensing software choices now that you needn't really worry about your code being stolen if you make a time-limited trial version available.

Tie the timeout date to the download date. I tend to download things when I run across them, which may not be when I have the time to test them. More than once I've run a setup program only to discover that the application has already timed out. Timeout dates should be tied to installation dates.

Don't forcefeed me the libraries. I already have .NET and Java runtimes installed on a whole batch of test machines. I don't have unlimited bandwidth. It's nice to provide a link to the appropriate download sites, and let me know which versions your software requires, but don't make me waste time downloading stuff that I don't need.

Don't work in a VM. With the widespread acceptance and availability of VirtualPC and VMware, the easiest way to test new software is to throw it into a virtual machine. This has the benefit of not making me mess up one of my "real" computers, and also lets me roll back changes to a baseline quickly. Despite this, I still run across software that won't function in a VM. If there's a good reason why yours won't (such as video incompatibility), make sure to document this prominently so I don't waste time trying.

Don't provide documentation. Time and again I download and install software only to discover that the documentation is sketchy or lacking entirely. If you're making software available for people to evaluate, this is just silly. If anything, evaluators need more documentation than continuing users. Tutorials and samples are great tools to sell your software. Don't run out of steam before creating them.

Fortunately, the majority of software I download to evaluate doesn't make these mistakes. That means I've still got plenty to write about, even after throwing out the packages that annoy me or actively interfere with evaluation. I feel sorry for their manufacturers, but I'd feel even sorrier for developers if I recommended putting up with this sort of experience.

About the Author

Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.


Upcoming Events


Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.