|
However, I always tell people I warrant my code for 24 hours. After that, I can't even remember what I did let alone guarantee it.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
One software publishing company I worked for had the policy that we would not ship with any known bugs.
We did not fool ourselves into thinking there were no bugs, but we did not knowing ship with any.
All copies were given a serial number and as bugs were located and fixed, an entry would be made into a database of the problem and the serial number that it was fixed.
When customers called with a problem, tech support would look in the database to see if the prblem had been fixed if the customer's serial number was below the fix number, a new copy would be sent to them. If the problem had not been fixed, it was passed to the programmers to investigate.
When fixed, it would be noted as above, but in addition, the customer that brought it to our attention would get a new copy.
We didn't send out new copies to everyone, only to the people that complained. Not everyone hits the bugs.
We used to joke and say "Quality in the works...we're still working at it."
This, I felt was vastly superior to a later company that I worked at that shipped their product with 150 known bugs. These weren't trivial bugs, but system crashing. The customers finally rebelled and made it clear that they didn't care how many features the new software was going to have if it didn't work. This led to a cleanup project and a VP calling us, asking how to log off, because in the 7+ years they had been shipping the product, it had never stayed up long enough for him to need to do that.
As to having a warranty, I think the software should have one as long as you, and not the customer, determines if it is a legitimate bug. Some people are never happy and will complain just to hear themselves complain.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
My initial reaction was, "I'll offer a warranty when the company I work for offers me royalties!"
Cheers,
Mike Fidler
|
|
|
|
|
Yes, if the code breaks within an agreed warranty period (like any product). I usually give 3 months warranty on a product after it has been accepted and no further development is required.
No if the warranty period has passed and like any product, the defect can only be found if the product is used. Do you ever get warranty from a manufacturer if after a year you say: "But I have only started using it now and it doesn work"?
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
I agree to a certain extent.
The way I read the question was that regardless of how long the warranty period was do you fix it or not.
This was the word that stood out the most for me. "If our code breaks should we be legally liable..."
My answer is similar to yours... No. We can "give" the customer a grace period or a warrant to fix this if anything arises during that time. Which I agree with doing, but should we be legally binding to fixing software regardless of if it is out of our predetermined warranty period?
|
|
|
|
|
I agree with you. I believe there should be no legal bearing and all should be done through contracts if the customer want some safeguard.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Unlike many people on here, I have not worked as an independent consultant where I sell my time/wares. I have worked for multiple large corporations, however, in manufacturing enviroments.
As such, I was paid to write code, my employer was my 'customer'. Should I be told after I have left the company that I need to come back, on my own time, to fix issues that have come up?
Even if my code has been left unaltered, does that mean the underlying enviroment is identical? What if the OS has been upgraded or new versions of libraries installed? Am I then responsible for determining that these changes are causing the problem? And, if I spend the time to determine that, what is my compensation for identifying a problem I am not responsible for?
Here are some real-life examples:
- a reporting system is using Crystal Reports; the organization changed versions and the reports no longer work
- a system that generates truck weight tickets is designed to use a dot-matrix printer for speed of printing; the PC is upgraded from Windows 2000 to Windows XP and the tickets no longer print the same due to a difference in the print driver
- a system reads information from a flat file on a server it only has read access to; the format of the flat file is changed by a third party; who is responsible for the data read no longer working?
Tim
|
|
|
|
|
I consider each of these questions to be very simply the responsibility of the customer. In each case, _they_ have modified the operating environment. In none of these cases has your work been shown to be defective/deficient.
If I put leaded petrol into an unleaded car and poison the cat(alytic converter in the exhaust pipe), it's my fault. The two versions of the same fuel are _not_ forwards/backwards compatible. Certainly, unleaded is the successor to leaded, but that doesn't make them the same thing.
So,
1) Their responsibility. Just as I could expect some things to no longer work when I changed from XP to Win7 or Win8. Write permissions in the "Program Files" folder is an obvious enough example.
2) Again, their responsibility. The operating conditions have changed. You made a tool to fit the environment, the environment was since changed. It's little wonder the tool no longer fits well.
3) Surely, you jest? Obviously the responsibility of those with write access to the flat file.
It's a pretty basic task to specify the operating environment supported and add caveats that explicitly explain that deviations from said specs may be functional, but will not be supported without incurring further costs.
It really can be as simple as "Strictly for indoor use only" as seen on so many electrical doodads.
"Science adjusts its views based on what's observed. Faith is the denial of observation, so that belief can be preserved." - Tim Minchin
|
|
|
|
|
Terms and Conditions could clearly indicate the scenarios and scope for warranty.
|
|
|
|
|
lets remember what the survey is asking, should you offer a guarantee for BROKEN code. which implies code that as been missed/overlooked through the debug process. That is your fault, you cant argue with that it just is. so if your charging for the work you carried out, you should fix your mistakes.
Other than that what else would you be charged for? as long as the original logic was followed and the client got what they wanted why would you need to fix it?
that's my 2 pennies worth anyway...
|
|
|
|
|
I agree, of course you should fix your mistakes.
|
|
|
|
|
.. because the survey statement included no limitations to the warranty other than the damage exclusion. Based on those conditions, that means that once I have sold a piece of software I have to support it for all eternity. I am liable to fix bugs even after it is no longer technically feasible to do so. I've had customers try to stick me with those conditions, and it simply isn't reasonable.
I produce a quality product, and I want my customers to be happy with it. In my day job we routinely give customers free software upgrades for the life of the product, given that it's a multi-million dollar hunk of iron and the software just makes the thing go. For my after-hours consulting I will fix reasonable errors for a limited amount of time, and I'm the judge of what's reasonable. I won't handle specification changes and feature requests without negotiation.
Software Zen: delete this;
|
|
|
|
|
Shocking to see the results of this survey. If I buy an expensive item I would expect a guarantee for a time period.
In the same token if you provide source code at a price then you should guarantee it. This does not even need to be explicit. If it does not work then you fix it because you wrote it.
How is it ok to charge for broken code and then charge extra to fix it?
If you provided the code for free then the situation is different. Nobody expects a guarantee with free stuff. But, if you have charged, have some pride and fix it, no questions asked.
Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.
~ Albert Einstein
|
|
|
|
|
Agreed. It's about taking responsibility. There's too little of that nowadays. (Listen to me, sounding like somebody's grandpa.)
|
|
|
|
|
No seriously, think about it. Holding companies responsible for their crappy code sounds great, right? And maybe it is.
But regular people can't afford to be haunted by all their past projects. No one would ever release a pet project again. Too risky. Open source would be in serious trouble - many projects won't be able to survive by relying for development just on the companies that use them. Software would became like hardware: you can tinker in your shed, but almost any actual "product" is produced by a company.
|
|
|
|
|
I think you can safely exclude open source projects from this. I mean.. yeah you can give the user a full refund if it doesn't work... like "Hey man, here you have your 0$ back that you paid us for this software" 
|
|
|
|
|
Ok. It would still apply to free open source if fixing is mandatory though. The question didn't really clarify whether the choice implied by the "or" is to made by the developer or by the lawmaker.
|
|
|
|
|
Hm. I hadn't thought this way. From
Quote: If our code breaks should we be legally liable to provide a repair, a replacement or a refund
I understood that the developer is just liable to provide either of those three. It could, however, also mean that the user is the one to choose what he wants.
|
|
|
|
|
I read it as warranty for 'sold code' as in source code. So answered no.
But for actual 'finished' software (not that I've seen a finished software product yet), then yes they should come with warranties.
|
|
|
|
|
One user complained that her PC/application was no longer working as before.
I swapped out the monitor first. Issues persisted.
I swapped out the graphics card. The issue persisted.
I swapped out the PC, carefully copying all her applications to the hard disk of the new PC. The issue persisted.
Turned out that the idiot had downloaded and installed the Aquarium screensaver; you know, the one where the little fishies swim around on your screen.
It was a TSR (terminate and stay resident) program that caused the havoc.
Took three days to resolve and three roundtrips from my site to user site.
If I had known that at the beginning, I would have bought the twat a real aquarium at K-Mart for $20 and saved myself a lot of aggravation.
NO FRIKKING WAY!
|
|
|
|
|
Why is that an argument for "No"?
It's a software problem with the screen saver...
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
It was viewed by the user as a problem with the ERP software.
It was not.
I was required to fix it.
I spent my time and energy fixing a problem that I didn't cause.
Who is going to sue the provider of the free Aquarium screensaver to compensate me for my efforts?
|
|
|
|
|
If your software doesn't do what I asked it to do, fix it or pay me back. Period. No excuses.
Will Rogers never met me.
|
|
|
|
|
Damn right!
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
1. Because the development cost would be far too high to develop anything.
2. It is nearly impossible decently calculate the risk, developers are not "material" that can have a measured strength or reliability. (hence #1)
3. Many suppliers already do deliver some sort of warranty, based on a a certain amount of free "bugfixing", guaranteed passing of test scenarios, etc...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
