A discussion rages (in many forums, at this moment in my hotel room) about What Software Is Worth and What You Are Paying For When You Buy It.
There are many philosophical arguments (going on in this hotel room, even) but I am going to give my opinion as a consumer here.
To me, as a person who buys software, I see it this way: I am paying someone to get software. Sometimes I pay the person who made the software. Sometimes I pay someone who happens to be publishing the software.
Once I pay someone to get the software, I should be able to do what I want with it. I am willing to pay for support of that software and other services (online play, ahoy).
A software producer may think they are selling me a license to use their software (on N number of computers, perhaps), but whenever they try to enforce that, I generally find myself inconvenienced.
If I find that the cost that the publisher/producer expects me to pay for the software is more then I am willing to pay, I will generally disregard what they want and get the software from someone else (or use the original software in a manner that the producer/publisher considers illegal).
This may include using one license on more computers then they expected. Or downloading their software using bittorrent.
2008-04-07
2008-04-06
Customers
I think I've realized why talking to customers can be such difficult work.
When you are talking to a customer as a developer trying to figure out what your software needs to be able to do, they always describe their tasks in terms of the steps that they take. Instead of saying "In order to properly do my job, I need to be able to order any number of products from a vendor and assign them to these tasks" they say "In order to do my job, I open screen A and fill out fields B and C."
As the developer, it is your job to find out exactly what happens on screen A, and exactly how important fields B and C are to the process of... whatever it is they are doing.
If you call back later to support your product, they never say "I was filling out field D on screen E and the program crashed when I hit submit" - they always find it more meaningful to describe the problem "I was ordering products from a vendor, and the program bounced me back to my desktop."
Never mind that you can order any random product from a random vendor on their computer without any errors - there is some combination of fields that when filled out causes a horrible crash, and all they can remember is the abstract of what they were doing the last time it happened.
When you are talking to a customer as a developer trying to figure out what your software needs to be able to do, they always describe their tasks in terms of the steps that they take. Instead of saying "In order to properly do my job, I need to be able to order any number of products from a vendor and assign them to these tasks" they say "In order to do my job, I open screen A and fill out fields B and C."
As the developer, it is your job to find out exactly what happens on screen A, and exactly how important fields B and C are to the process of... whatever it is they are doing.
If you call back later to support your product, they never say "I was filling out field D on screen E and the program crashed when I hit submit" - they always find it more meaningful to describe the problem "I was ordering products from a vendor, and the program bounced me back to my desktop."
Never mind that you can order any random product from a random vendor on their computer without any errors - there is some combination of fields that when filled out causes a horrible crash, and all they can remember is the abstract of what they were doing the last time it happened.
Subscribe to:
Posts (Atom)
