|
With you there, brother!
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.
|
|
|
|
|
From https://www.schneier.com/essay-228.html[^]
"There's no other industry where shoddy products are sold to a public that expects regular problems, and where consumers are the ones who have to learn how to fix them."
The whole article is well worth reading...
|
|
|
|
|
After development there is testing so if it passed development and testing no warranties should be on developer nick.
|
|
|
|
|
I think you are wrong: You are saying that if someone random tests a car I designed and didn't find any problems, then I shouldn't be liable for the brake system failing completely if you exceed 100mph on a Tuesday? Or the car overheating and bursting into flames[^] if you drive it too hard? Tell that to people who bought Ferrari F458s!
No, I'm sorry, but you have to accept responsibility for your mistakes. You can't just palm them off on the testers "not doing their job" because you don't feel it's your problem once you hand it over.
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.
|
|
|
|
|
I remember a day at the beggining in the firm I work for. I cam one day to the office and one of the seniors was looking to the roof and playing with a touch panel. I asked him, what are you doing?
His answer... "playing dumb user"
That got me thinking for a couple of hours... and I took one of my current projects that day. I had tested it and was working fine.
Then I tested it blindy touching buttons in random order. I found 10+ bugs within 10 minutes.
Testing a program you have developed is a "tricky" test. You do things as they are supposed to be the correct sequence. But the biggest problems are always the exceptions and random clicks.
the conclusion... no matter how hard you test, there will always be a user that finds out how to screw it up.
So... if the problem is in your code... yes, it is your fault.
If I go to a mechanic and give my car to change the wheels and after 200 km one wheel gets out of the place because it was not correctly fixed, I will ask for warranty and a free fix and even an indemnization if I had an accident. If you program something, and there is data loss and the problem is in your code, then it is totally legitime that they ask for responsabilities. Another thing is that your code works good and they used it wrong. Then is as if I full my tank with diesel, but my car is benzin.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Considering that developers have little to no control over the operating environment where the code is used, it is effectively impossible to validate the code will work as advertised everywhere. The possible interactions to consider are intractable.
I've seen code that has no audio features fail when the user played a music CD to pass the time!!!
|
|
|
|
|
Most of us can probably agree that it's our responsibility to close the entire loop with our customers. This would entail developing, documenting, and even training the folks who would be using the application. Because let's be honest -- if we don't do it, there are enough irresponsible people in the way who will drop the ball, and we'll look like the bad guys in the end. Go the extra mile - customers will appreciate it and you'll eliminate a lot of hardships on yourself and your colleagues in the future.
|
|
|
|
|
Needs the option "Depends" with ability to include free-text reasons qualifying the "Depends".
My Answer: DEPENDS
Qualifier(s): Just watch the movie "RoboCop" ...
'nuff said.
|
|
|
|
|
Then, again, if someone is programming robots for the outcome that such the robots in RoboCop can perform, the recipient of the robots would either be scared poopless to even dare make a claim on the warranty  or wind up receiving the full capabilities of the robots should they invoke the warranty. 
|
|
|
|
|
All software has errors. I don't want to refund money to someone who finds a one pixel off alignment. On the other hand, if the defect fundamentally prevents them from achieving the results they purchased the software for, then I'd be really unhappy that we failed them, and I'd be the first to offer a refund.
|
|
|
|
|
If there is a QA then the responsibility should go to the QA first. Otherwise it should go to the developper who wrote the code or who integrated the codes, based on the situation.
|
|
|
|
|
I am all for promoting honesty, cooperation, professionalism, clear and clean code that works. Warranties for code is a tricky topic. I see it as entwined with the contract, the project management, the project team, the technology base, the code base, etc.
If you are part of a team then how can you completely warrant your code? The result is only as good as the weakest link in the project. Maybe if you create a HASH of each file in your code and have that as a stipulation in the contract. I have done this and avoided recourse when the user group tinkered themselves or with a third party that did not have the skils to make the changes correctly.
If you are the only developer then what about the frameworks and assembiles, DLL, etc. that you use or are asked to use? They can be flawed or maybe incompatible or inappropriate in ways that you could not predict. They may change after your project is developed introducing problems.
If you warrant the code then the contract has to have a bunch of clauses on time periods, changes to frameworks, etc. It is a lot cleaner to just offer is as is (working to spec. of course) within the estimate and create new change orders for additional work. That helps keeps everybody honest and encourages building a cooperative relationship.
The best projects I have done included a lot of milestones and adjustments made at each point to the scope and costs. The worst ones were one estimate and all kinds of changes that were ultimately expressed with gems like "well of course it would have to do that also", "we expected you would have added that, any good system would have that", " I am sure we mentioned we would need that too", "Bill expects that to be in there though", ...
My comments are a bit broader scope than the question but I see this question as having that scope realistically.
Hope this is helpful.
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
|
|
|
|
|
You know... it really depends on the severity of a bug.
Just because a product could crash on some rare occasion doesn't mean you're not able to use it at all.
I agree, however, that you should be legally liable to provide a repair, a replacement or a refund, if you are unable to use the product at all, as long as you're taking money for it at least  I believe in the EU there is a law that you can return a product for full refund within lets say 2 weeks or something like that (also applying to digital products), but I might be wrong about that.
For those who care that a product works like they expect it to there are already contracts called Service Level Agreement (or SLA for short), where you can get a warranty for paying money.
|
|
|
|
|
Yeah, we sell a contract with all of our software that will provide additional support when you need it. You'd be surprised at how reluctant people are to pay for it, then they get angry when they need something and they failed to pay for support.
|
|
|
|
|
First of all, developer's code is a fraction of code, involved in a whole process, from click on button till real click handler. How you can guarantee that your code works, when hindu dancers developed half of Windows?? I don't bet even a cent on Windows system, which worked at least a week - soon or later some sh*t happens and you need to restart it. Funny, but even Win8 cannot work without being interrupted by HDD! (when application does intensive access)
Until you wrote a whole system, you cannot guarantee any work. And even making that, you still not sure that you control all stuff - overflow, security, etc.
Modern systems are TOO BIG to guarantee anything at all, read MS agreements - ALL their software sold AS IS, means you pay, but use for your own risk. Period.
|
|
|
|
|
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...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
