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


_______________________________________________
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.

Reply via email to