Shopping for software. Who's job is that in your company? Some organizations are looking for the best price. Others are looking for satisfaction of requirements. Some are required to find products with serious support. Again, who shops? Is it a junior engineer on a new project? Is it the purchasing department?
Since there is such a wide variety of software products, this discussion will be confined particularly to system software packages or libraries that perform commonly needed functions and shorten the application development cycle. You may be able to write them yourself, but would prefer to find something that is already written so that you can focus on your core competency.
Serious Software Shopping
Shopping for such software should not be taken lightly, as its outcome can have major impacts on a business. I would bet that most software engineering organizations have no policies for the process. So I would argue that the software shopping process should be defined by purchasing/using organizations and supported by providers.
The analogy with personal shopping must be addressed. Why? Because software shoppers, especially those interested in the data management industry, can learn something from personal shopping. While it has changed substantially in the age of internet, the ability to decide between competing options still requires physical contact with the products. Even when I buy something from a web site, it is rarely something that I haven't already experienced directly. But how can software be touched or used or tasted? What is the equivalent of a test drive?
What the industry has offered so far includes tons of marketing claims, downloads of complete products, example programs, and perhaps interactive tutorials. Online manuals, white papers, technical specifications and use cases are all offered by providers to help with the process. All these pieces are necessary, but when there are several choices, there is not enough time available to study them all. Whether the software shopper is a beginner or an expert, the process is cumbersome at best.
Benefits of Providing Samples
Back to the personal shopping analogy - a test drive or small sample often provides enough information to know whether further investment in the process is needed. After all, if you don't like the product when it is presented at its best, it's unlikely that more time investment will change that. If sampling takes just a few minutes, then even if you don't like it, the vendor has done you a favor by providing it. But if you do like it, then your investigation can proceed with more confidence.
Sampling in the Software Industry
Samples are not examples. Examples exist everywhere, from within installed products to online libraries and blogs. If an example is shown in source code (say, C++), it is frequently up to the readers to interpret it in their head. Examples typically are complete programs that show how a particular problem is solved. To execute an example, a complete product installation is typically needed. Installed examples should be configured to build with the installed product. Other examples may require the programmers to set up the build themselves.
I did a quick search of system software web sites a few months ago, and found none that "sampled" their software. Let me define a sample like this: it's a small download that contains the real product, but packaged so that it is ready to consume. It can be quickly installed and run without requiring any other pre-installations or configuration. Then after seeing what the sample does, it can be discarded without leaving a mess behind. No commitment and no investment, but enough to make a point. Hopefully, additional samples will also build on the first one. Samples don’t need to show how to solve a complete problem any more than a food sample needs to show how a complete meal tastes.
Supporting the Process
Upon seeing this glaring hole in the common practice of software marketing, I suggested that my company build a set of samples that fit this definition. The results are spectacular, in my opinion.
Two major categories of samples should be provided by a system software vendor: functionality and performance. The most common questions from software shoppers are "How do I use it?" and "How fast is it?" Both categories should have a graduated series of samples that go from the very simplest (like "hello world" but relating to the product’s audience) to the heavy-duty or advanced. If there are various interfaces or APIs, each one should be demonstrated through a parallel set of samples that solve the same problems. If the product targets multiple operating systems or CPUs, then samples for more than one (the main two or three) are warranted. If shoppers use certain development environments, then the samples should include complete, ready-to-use projects that include source code, readme’s and libraries, with no other prerequisites for the sampler’s system.
As I mentioned above, a software vendor should support a shopping process. Where internet has created a climate of instant gratification, software samples can satisfy that expectation.