Thanks again!
On 24/01/2014 11:00 AM, Ken Dibble wrote:
How do you handle "bugs" that only appear after the client has added
a new version of Windows or some other hardware which breaks your code?
I don't really consider Windows version issues to be bugs--that is,
defects in my product.
However, I expect my VFP software to run on any version of Windows
that VFP runs on, so if those issues arise, I will fix them if there
is no reasonable work-around.
For example, my software, for better or worse, reads/writes files
inside the installation directory, and also to the \Windows directory
(for semaphore purposes only). This is a problem on Win 7. The
installation directory work-around is not to install under C:\Program
Files\ and install directly into the root instead. Win 7 lets you
write to files in directories in the root. It will virtualize anything
written to \Windows though (unless you turn that off in local
policies), so my support website explains how to find virtualized
files on Win 7 if they need manual attention.
I'm working on a framework revision now that will address this by
writing to some suitable location that Windows will permit. That
update will be released for free when it's done.
My software can have hardware-related issues at times, specifically
with some printers. The company that produces our accounting software
used to say you can only use certain HP laser printers with it.
Although that was highly annoying, it was what I consider to be an
acceptable practice, and I would not consider it a bug if someone
wasn't able to use it with, say, a Brother printer. However, I have
never imposed such a restriction on my software, so I feel obligated
to make it work with any printer capable of printing on (American)
letter-sized paper. I will adjust report margins (the most common
cause of this) to continue to try to achieve the golden mean that
works with all printers, for free.
On the old (fix all bugs free) model I do well (financially) if there
is a lot of new development coming in. Of course, this then reduces
my response time to existing customers/projects as I have to give
priority to the source of the income. I do very badly if there is no
new work coming in (thank goodness my wife works!).
Since I believe that common law requires anyone who sells a defective
product to repair the defects for free, replace the product with a
working version, or provide a full refund, whether it's software,
cars, TVs, or houses, I don't see any solution to that issue except to
regard that as a cost of doing business and build it into the business
model. To do otherwise would (and should) make one vulnerable to legal
action.
Ken Dibble
www.stic-cil.org
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.