Slashdot Mirror
Ask Slashdot: How Long Should Devs Support Software Written For Clients?
lucky4udanny writes "My client says any software/website we develop for them should be supported with bug fixes forever, with no further compensation. We have generally supported our work for two months, to give the client adequate time for real-world testing, after which we charge by the hour for all support. How long should a company fix bugs without compensation in software they developed? What is the industry convention?"
Dude! The support details are something that you should have had in writing before you even started working on detailed requirements.
Both sides agree in writing on the scope of work, acceptance procedure, support, training, documentation, code disposition (work for hire, GPL, third party libraries, possibly even escrow), all of that stuff. Anything else just shows a total lack of professionalism.
If you are now in a position of being asked to support it forever without anything in writing you have to decide which will be worse, cutting your losses now and writing off that client and everyone they will bad mouth (with some justification but they are equally guilty of not insisting on getting anything in writing) you to or digging yourself into a hole providing free support until they eventually toss that codebase. Which one you choose depends on far too many factors you haven't provided.
Democrat delenda est
...one slip-up and you're gonna be supporting it for the rest of your life.
Prolly end up having to raise your own grandkids too.
Are they providing infinite amounts of cash in return for your infinite amounts of labor?
..and if you want to make a profit. Supporting a life cycle of software that has no terminating date can get you into some trouble because you are spending man hours at a cost supporting it.
" after which we charge by the hour for all support. How long should a company fix bugs without compensation in software they developed?"
You have your answer. You charge by the hour for support including bug fixes. Only slaves work for free.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
We do 3 months for custom / work-for-hire products, and hourly after that.
You have to be careful, because I've had companies that start making changes to their infrastructure, and then told us our software didn't work when in fact their environment changed. So be very specific.
has an ID-10-T problem
If they want lifetime support then price your services accordingly and offer that as a option. Chances are if you give them two quotes, one with your typical policy and another one priced for what they are asking for, they'll choose the one that makes the most sense.
I still think that even if it was your fault the bug exists, they should still pay you to fix it. I mean, every bug can't be your fault it is impossible to test every possible case and it's just part of the life cycle of software. Don't stop providing support as long as they pay!
You're kidding right?
Slashdot is proof that Sturgeon's Law applies to mankind.
it's not always mistakes that require support - a lot of times, it's feature creep or moving buttons around. Clearly, that's not something the dev should do for free. But yeah, support should be spelled out as part of the dev agreement.
>>They didnt code it, you did.
You didn't sign off on the acceptance testing, they did.
Really thats the issue.. whatever support you were willing to offer should have been put in writing and agreed on before work began.
The same sorts of things can happen during a project too. Get it all in writing. Clients love to change things as you go, and they'll do it until they break you if you don't tell them before hand they can't. IE, you give them say 3 mockups to choose from.. then once approved they can't come back at you and say thats all wrong we need the design changed. Same thing with the support. We all know you probably cant support the code forever without compensation, you have to tell them that or they will expect free support forever!
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
If you have a good enough support contract then the initial fee for doing the work is usually peanuts compared to the support.
All of this needs to be in writing, as part of the initial contract or else you will have no fun doing support.
My UID is prime and so is this number: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0.
There's so many different software industries, you cannot just ask "how long?"
For example, ATMs need to be supported for about 15 to 20 years. But a web hosting app? Maybe 5 to 7.
Basically, if your clients are paying you, you support them. If you no longer want to support them, you better be damn sure you have a robust, tested, and thoroughly vetted (and preferably heavily used) replacement product.
Hoist Number One and Number Six.
As long as the clients have paid for, as specified in the terms of the development contract (except insofar as the developer has an interest -- e.g., in developing goodwill -- that outweighs the cost of the support, or applicable law -- e.g., general provisions governing warranty obligations that the contract did not modify, either because the language didn't address them or because the law doesn't allow contracts to modify them -- imposes additional obligations.)
If that's all they want is for your company's work to be guaranteed, then why not?
Software has gotten an easy ride in regards to quality and vendors backing up their work. Might as well stand out from the crowd. I mean if another type of product had software's reputation, I would never buy it. Also, that company would be out of business.
Speaking of which, this something that's really hindering the medical software business. Folks are so used to software being buggy that their reluctant to adopt anything that can affect patient health.
Clients have a funny way of making everything into a bug. Customer changed their minds about something after they've already signed off on it? Bug! Your code doesn't run on an OS that didn't even exist when you wrote the software? Bug! Customer wants a new feature? Bug!
Protip: If someone is charging you to use Windows Update, you're getting ripped off.
There's no -1 for "I don't get it."
What are they going to do, cry about how unfair it is that you won't work for free?
People who want to abuse you always feel entitled to abuse you. It's their deity-given right, and how dare you question their rights.
Unless they have a written contract or something else legally compelling you to do it, they have nothing.
All that having been said, I find there is value in learning from my own mistakes, which is why I often look into claims of bugs or problems with the work that I have done. I generally put the foot down after 90 days though. I want to do good quality work, and if there is something quick and easy that I can do to improve past work, I'll do it. I get the benefit of realizing my mistake and not doing it again. However, I don't work for free and I try to set reasonable expectations with the client BEFORE taking on work to try and prevent disagreements before they occur. That's what contracts are for.
Why should they pay to fix your mistakes?
Once the client signs-off on it, they accept the bugs as well as the features.
Send them a can of mosquito repellent and be done with them.
If only there were some sort of body of legal precedent that allowed two parties to write down the salient details of an agreement in such a fashion as to make it reasonably binding...
Snark aside, the only 'right' answer to this question is the one that was agreed upon when the price was named. Longer support contract = more expensive. Shorter = cheaper. Option to pay per-hour or per-incident thereafter, and for how long thereafter, also preferably specified.
Some people make a business of charging crazy money, backed by the assurance that they'll still be there to hold your hand in 20 years. Some people sell you a box for $20 and tell you that they hope it doesn't break your computer. Certain consumer protection laws on the low end aside, any support term is a valid offering, supposing that it is priced properly.
Tell me what it is you do for a living? Because whatever it is, any problem that occurs with your work, ever, for the rest of time, I am going to expect you to fix without being paid.
Don't like that? Then perhaps reconsider your attitude towards this.
Uh-huh.
But they also ground you on price in the first place so much so that there was not enough room in the budget for proper testing / debugging. And don't forget that they changed the specs three times during development.
If a client wants software to be "BugFree" there's plenty of companies offering that level of service - IBM, WindRiver, etc.
Good, Quick, Cheap - Pick Two.
Not necessarily.
Bespoke software (written for hire) that is owned by the customer should typically NOT have an expectation that the developer(s) would come back and fix bugs for free, especially for a time and materials work arrangement. Fixed bids can be different, but typically the customer is responsible to certify that it's "acceptable" on delivery and final payment, and after that point they're on their own (i.e. have to pay for further changes).
Software like Microsoft's that is licensed or purchased does typically have an expectation of free bug fixes from customers, but unless it's in writing the customer should be prepared for the possibility that the company will refuse to fix it, particularly if it's old.
No one would pay the cost to write something that's 100% bug free from square one. Instead, you defer the cost and risks via a support contract. Standard practice and works out for everyone.
Generally three things should be decided before work has even begun:
- initial cost of development
- a warranty period
- ongoing support agreement
Of course, clients can pay up-front for, say, 10 years of support. But they only get what they pay for, no matter the details.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I charge people to run Windows Update for them, so I'm getting a kick, etc. ;)
If they want perfect, bug free code, then their developement time better be in the hundreds of years. If they want bugs to be fixed that you didn't have time to fix during developement, then they better be ready to PAY you to keep working on it.
Bugs = defects
Bugs != regular matinence.
A 60-day acceptance period sounds generous to me. Have them sign off on an acceptance letter. After that, it could be hourly, or they could pay monthly support that covers things like pro-active security patching and the right to call you with questions.
Major software packages are sold with support. Oracle, for instance, gives their salesfolk lots of discretion to negotiate price, but *not* to discount the monthly support contract. That should tell you something about how the big boys think.
I sure would not want to program for you. In 25 years of independent development, I only saw the bizarre belief you express from a single one client. I gave them two alternatives:
(a) "After the initial acceptance period, we'll fix all bugs for free...but of course you need to pay my team for 5-man-weeks of testing and QA time so that we can both be assured it's perfect first", OR
(b) "You'll pay us time and materials to fix any significant bugs you find, but we'll only charge you for 5-man-days of testing and QA time beforehand and you'll work with us to discover any others we missed as you use the software."
Needless to say, not being stupid, they took option (b) and we probably only ended up charging them for a few minor fixes.
A software bug is not "a mistake". It's an inevitable part of the process, one that can be mitigated by good design, good coding, good management, and good testing. But all of those things take time and money. There's no magic zero-cost shortcut to perfection in any non-trivial project.
I'd say if you've made some obviously boneheaded mistake, something that you should have seen and fixed, then yeah, bite the bullet and fix it for them.
On the other hand, if it's the kind of day to day stuff that comes under the heading of "maintenance" then charge them.
Car analogy: Recall and repair of a manufacturing defect (Manufacturer pays) vs an oil change and brake relining (You pay).
Three Squirrels
They give you an unrealistic dead line.
bugs are to be expected.
The EU tends to think 2 years for bugs... I think you should have really thought about this before writing the first line of code but hey it's not like this could end in a lawsuit or a reputation problem or anything...
Give them a copy of the source code, and if they don't like what you charge for support, they can hire somebody else to do it.
Of course if they come back later and want you to fix whatever their el cheapo programmer did to your code, they're going to have to pay extra. ;)
Offer them a service contract.
Maurice W. Hilarius Voice: (778) 347-9907
If you want support for any product you have to pay for it; either by contract agreement (low risk to business), pay as you go (low risk to contractor), or having someone on staff to maintain it.
come on fhqwhgads
Long answer: as long as they are willing to pay you at a competitive rate.
For websites, we offer a maintenance contract that covers a few hours each month, to be used for bug fixes or upgrades. Unused hours also "roll over" into the next months, and we use those for small feature upgrades.
Should have all been in the project charter.
No one in their right mind should support "forever", and any client who is foolish enough to demand it can go elsewhere. Anyone who says "yes" to those terms will be bankrupt by the idiot clients who demand that service. The fools who want that service will find that they have software that the vendor no longer exists to torment.
You should sell support contracts along with your software
Having been a developer for over 30 years. Unless the application is downright trivial in nature, I believe that two months is much too short a time frame to provide bug fixes. It should be at least 6 months. Now to be clear: these are bugs (i.e. things that you didn't do correctly), not enhancements or improvements to the application. Some complex applications don't exhibit their underlying problems (bugs) until much later or when they are under significant load (which can take a while)
As others have pointed out, you REALLY should have agreed on this up front and even provided a support contract that makes you money while providing the customer with support for the application for several years at least. You can't work for free, but you can't overtly charge for your mistakes either. A service contract protects both entities in the relationship.
So, what if the customer upgrades some piece of software in the environment that is a dependency of your software - a jvm, or .net runtime, or a library, or a database engine, or the operating system or webserver. Something breaks. It breaks not because of any mistake you made, but because something in the dependency changed. Maybe a bug was introduced into the dependency, or a deprecated function or feature was removed.
Should you be expected to update the code to deal with the new version of the dependency, for free? A lot of "bugs" that show up after 2 or 3 months fall into this category.
What if the "bug" exists because of a demand made by the client during development, and you even tried to warn them that this was a mistake and would lead to problems, but they insisted, so you gave them what they demanded, not what they really needed. Then, a year later, they finally come to their senses and want it "fixed" - should you be expected to do that work for free?
Little bit different - YOU charge, microsoft isn't. They are paying you to read the manual so that you know what button to press, and to press it. They don't want to know about it.
If you want a car analogy, this would be like paying a mechanic just to check your oil level, because you never could be bothered to find out how.
Ditch idiot customers by charging them exorbitant rates REGARDLESS of the demands.
You will never be able to educate the idiot to your benefit.
And idiot does not mean ignorant - it's a fine line but idiots don't learn or listen.
I stay very busy with good customers who respect me, listen to my advice and purchase my products.
6 months, out of courtesy. but really, your not required to give any sort of ongoing support unless its in some sort of written contract in place stating how much you will do for free, and for how long, and how much everything else will cost the client. its usually best to aim for a £100/hr for software dev and set your self a minimum amount that you would be willing to work for.
portfolio
Why can't it be both?
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
...release your clients' velociraptors if they make you fix their bugs for free.
>90% of "bugs" are features, conditions and behaviors not covered by the systems design.
Industry convention, by which I mean what companies like IBM and their ilk do to customers, is they deliver crap to their customers then charge them an arm and a leg to fix it. I don't know that industry convention is particularly helpful when you're a small time guy trying to earn a living.
Like others have said, you should agree to a sign off period, but if you want to make your customers happy, you might consider fixing the worst most serious cases of bugs for free for a lot longer. But you would restrict it to really blatant bugs.
If maintenance and updates aren't clearly spelled out in the original contract, if the client wants work done outside the scope of that contract, then it's time for a new contract that specifies service provider responsibilities and client remuneration in exacting detail.
On the one hand there's "if it's worth doing it's worth doing right," and on the other hand it's work for hire. If you're not getting paid - if you haven't already been paid - for the work in question, then negotiate. Don't do it gratis.
For certain definitions of the the term, sure, it's both; for others, not.
"Mistake" was put in quotes in what I wrote because of the original poster's implication was that all bugs were things completely avoidable, serious failures that were something the programmer should rectify for free and that not doing for a customer so was immoral/improper - like mis-assembled car that should have its manufacturing defect(s) covered under warranty. Custom-written software isn't in the same category, IMHO. If you want perfection, you have to pay for testing to perfection - not something most clients are willing (understandably) to do.
sorry, I forgot to use the "tongue in cheek" font.
Well, if you have a proper Quality Assurance in parallel with your coding (but real QA, not only monkeys checking UI), the amount of bugs will be minimized. So, in the contract, I always specify: clear bugs will be fixed. Any issue that is more to feature request, will be cost estimated.
There's no easy answer to what is "typical" because so many variables exist, especially with custom software. A common model for non-custom work is an annual maintenance/assurance contract. Client's buy the software, and get one year maintenance. After that they pay {x} amount each year to renew that contract. During the life of the contract the client is eligible for support and product updates.
Two of my imaginary friends reproduced once
supporting software indefinitely is like buying a car and asking for infinite replacement of parts forever.
But I do agree on a small "warranty" period, which may range from a few months to a year, just so that most bugs gets corrected but after that it's "mechanic billed by the hour".
In fact, I believe more than half of world population doesn't anything for all the software they use, no matter where it comes from. If you are among these software giants that can afford to have so many non-paying clients, and write it off as "marketing costs", good for you. But most of us aren't quite there, and we charge by the hour.
For the large contracts I have been part of the contractual arrangements typically include a warranty period of 12 months for latent defects, that is things that are not functioning as agreed in the specification and could not reasonably have been expected to be found during the agreed customer acceptance testing (the equivalent of a pre-purchase inspection for a tangible good). For example; the software is specified to handle any Standard XYZ message, a wide range of messages were tested and the software accepted, but an unforeseen, legitimate real-world message breaks the live system. Everything else involves a fee to change the contract, which includes the specifications, and do the work. They hire people to be bloody-minded about what creeps into the "latent defect" category. For high risk projects they will take out insurance against the possibility of latent defects (and charge the customer indirectly).
Patent litigation: A doctrine of Mutually Assured Destruction... in which everyone seems willing to push the button
Because they didn't pay enough to have it written correctly the first time.
Some people have tried car analogies that don't work. Here's one that does.
Car manufacturers cover certain SAFETY related defects indefinitely because the govt requires it (or maybe because they believe it's cheaper to fix than be sued). However, they generally only cover manufacturing defects for the duration of the warranty. They don't "fix" the car when environments and specifications change. e.g. Cars designed for leaded fuel weren't retrofitted to use unleaded fuel (although high octane unleaded fuel would usually work), and the manufacturer isn't going to update your car because a tire manufacturer stops making tires in the specified size. These things are the responsibility of the buyer.
Same concept applies to most other products, why should software be any different?
It shouldn't. First, have a contract the specifies the requirements, and specifies a length of time during which you'll offer free support for bug fixes or failure to meet the specifications (even if they signed off on it since sometimes it's not practical to test all specifications on delivery). Changes to specifications, including compatibility with other software/systems, and bug fixes after that term are chargeable items. For chargeable items, the developer (company, not necessarily the individual programmer) may at his discretion choose not to charge, but it's entirely up to the developer. For trivial fixes, it's often more trouble to create and handle an invoice so you might choose not to charge, and that fosters good customer relations. For larger issues, you have to consider more factors, just like a vendor of any other type of product.
make imaginary.friends COUNT=100 VISIBLE=false
It can. Usually isnt.
The only software that has absolutely no bugs from the rollout is code more than 20 years old that hasnt been touched in the last 10 and does exactly what it did back then.... and even then, sometimes the unexpected can come up way in the future.
You have no idea of how software is made, do you?
NO SIG
If they want bugs to be fixed that you didn't have time to fix during developement, then they better be ready to PAY you to keep working on it.
Read:
"You want us to program some software for you? No problem. Oh, you wanted software that actually works? That costs extra."
Seriously, if you're knowingly writing bad code just so you can charge people to fix what you should have done right in the first place, you won't stay in business long.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
If the OP actually owns the code and he/she gives the client a copy of the source code, then they also need to have the client sign a Non Disclosure Agreement or the OP could end up in a worse situation. It should state the client can't disclose or sell the code and use it only for internal purposes, etc. etc. etc. Imagine a system where all the code you spent time and money to develop is given away and anyone who wants it can use it. You'd be out of business. And you wouldn't be able to pay off the bills you incurred while not making money while writing the initial code. But very, very often the code ends up being owned by the people who commissioned it to be written. This would then invalidate your point entirely.
-- I ignore anonymous replies to my comments and postings.
Indeed, though a service level agreement is always worth having. That way everyone knows ahead of time where they stand and whether to end the relationship early if the terms are unacceptable to either party.
Always get the user to end user testing and to sign off on it. If they refuse to do so, then you should indicate that you aren't liable for bugs that could have been caught. Anything caught outside of the testing period is subject to the SLA.
As to source, big companies sometimes insist on either having the source or keeping it in escrow, in case you disappear, but having infinite life-time support for free is excessive. Is there anything in life that comes with type of deal?
Note, if a contractor fixes my roof then I have a guarantee against defects for 5 years. If it runs into problems that are due to their workmanship, then they have to take care of it.
Jumpstart the tartan drive.
So they can test to reasonable levels of assurance.
For custom software work, that level of testing is generally too expensive to give unlimited guarantees.
Uh-huh.
But they also ground you on price in the first place so much so that there was not enough room in the budget for proper testing / debugging. And don't forget that they changed the specs three times during development.
If a client wants software to be "BugFree" there's plenty of companies offering that level of service - IBM, WindRiver, etc.
Good, Quick, Cheap - Pick Two.
Even then there is no bug free software. What it is free from are bugs that testing would have discovered. Anything after is subject to the SLA (service level agreement)
Jumpstart the tartan drive.
Seriously. If you aren't using ATDD (Acceptance Test Driven Development) and TDD (Test Driven Development), then you have no excuses. Support them forever. I consider it unprofessional to release software with any known bugs and I have been doing this successfully for 10+ years. ATDD proves to the client that you have built what they want and that it functions as they expect (this is your contract) and TDD proves to you yourself that the internal quality of the code will hold up as well (very low rates of unexpected problems). Defects are preventable.
Think of this like surgery: if you are being rushed into the OR, you don't yell at the surgeons and nurses to NOT wash their hands and just dig into you. And even if you did, they would ignore you. ATDD and TDD are a lot like washing your hands before surgery. If you don't do it, don't be surprised at the consequences... it can be fatal.
Helping with organizational effectiveness is our job.
Make some minor/major tweaks, repackage it as Version 2.0 or whatever, and tell them that the old version is no longer supported. Then you can negotiate a service contract for the "new" software.
Hey, it works for the big dogs...
An enigma, wrapped in a riddle, shrouded in bacon and cheese
On the other hand....
Forever is a long time. There is no reasonable expectation of forever in any legal contract for goods or services in any
industry I'm aware of. Even contracts for burial plots do not last much more than 200 years.
Sure, a wise contractor will have a warranty duration mentioned in the contract, and specify an acceptance testing phase, after which
all bugs belong to the purchaser. Any bug fixes offered after that are likely to require additional payment.
Without such a Ts Crossed and Is Dotted contract, there are only reasonable expectations to fall back on:
Both sides know that there is no such thing as bug free software. Never has been. Never will be.
Expectations to the contrary are not reasonable, and never have been.
Expectations of indentured servitude went out with the 13th amendment, and no contract can bring that back.
Further, rare is the software that enters service and remains unchanged for its useful life. Any warranties or assurances
are lost once the code is modified, even if modified by the same developer, but especially when another developer
steps in, or the purchaser themselves make changes. Even without a contract that states this, one need only
point a finger at the changes made by others to divert ALL blame.
The two month time period mentioned in the story and "adequate time for testing" seem a little thin if you ask me.
I would never sign a contract for custom software that was so tightly limited, and it does not sound reasonable for any project of any reasonable scope.
So without something in writing, the contractor deserves a little pain and suffering (as a stupidity penalty), but they are STILL not up the creek without a paddle, because "forever" is not reasonable, and reasonable expectations become the deciding factor. But in this case "reasonable" is no longer strictly the contractor's call, and courts may well have a say.
Sig Battery depleted. Reverting to safe mode.
Then there is no obligation to do so. Anything after initial testing is either out of the goodness of your heart or a change request outside the scope of the original contract. If you didn't specify an initial testing period during which defects would be fixed at no additional cost in the contract (or verbal negotiations which are nearly as good, for your purposes) then my understanding is the default would be your state's default under fitness for purpose, or similar. These tend to not be favorable to the buyer.
Get a lawyer to do a support contract. Secondly fire the client they will never be happy.
The effect of testing has diminishing returns on software quality. At some point it will become cheaper to fix bugs after the software is released than to test to perfection. Some customers demand perfection the first time, while others don't. For example, avionics software tends to be biased toward the "test to perfection" side, while general applications can usually be fixed after deployment at low cost.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
I started programming professionally when I was still at uni. My first two projects were defence support contracts for applications the company had supplied a number of years ago written in VBscript. Horrible architecture, but the things worked ok and they were reasonably well documented.
Then came the horror of the client I will refer to only as SS (appropriate). Shifting goalposts (I'm talking daily, it made keeping a good SRS impossible), uncooperative people who had written the original application, lack of experience with C# and a lack of project management experience on my part meant it was an abject disaster. Client was miffed, I was disheartened, boss was on the warpath with the client for harassment, all because she expected something for nothing and that we insisted on upping the price when she changed her mind from wanting Joomla, back to wanting the original custom code (which was a mess, I found I could get into the admin panel without logging in and a glitch in the credit card gateway that meant a massive disclosure hole) and then adding a bunch of requirements that made no sense, back to wanting a Joomla plugin. Horrible, horrible mess.
What I learned from that is that clients are stupid, and should be mostly removed from a fixed-term project except when signing off on it. Yes, bugs can be your fault, but, as has already been mentioned, clients can have the stupidest idea as to what constitutes a bug (much like the IT support arm I also worked in never let clients set their own priority, that was left to our dispatcher). A support contract that details exactly what your obligations to the client are, the channels through which they can raise requests and having a good paper trail are definitely your most important tools here. Process is a very useful tool for protecting yourself, learn how to use it properly
Yes. Provided they are running it on the OS and version you specify. With the supporting software versions you specify. On the chipsets you specify.
Any changes or if they fail to install appropriate security patches and all bets are off.
By the way. Only support defects and not Requests for Change. (They can want a new feature enough to pay for it.)
A sig is placed here
To display how futile
English Haiku is
Even outside of code anything instruction that can be misinterpreted will probably be, due to assumption of the person interpreting the instructions. In writing software we do our best to avoid misinterpretation, but given the amount of instructions, there is bound to be things that don't work well together.
Other domains where you run into similar issues and limitations: laws and medicine.
Jumpstart the tartan drive.
They give you an unrealistic dead line.
bugs are to be expected.
But what is unreasonable?
One metric for a largish task is documented in TeX.
D. Knuth commented that the test code took ten times as much work as the code itself. Even so bugs were found.
This tells me that most bids are 1/10 the cost of bug free code.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
"My client says any software/website we develop for them should be supported with bug fixes forever, with no further compensation."
If the client hired you as "work for hire", they get what they get once the contract is complete. If they want further support, they'll have to pay for it.
Maybe you should ask the client to do all kinds of work for free.
"Seriously, if you're knowingly writing bad code just so you can charge people to fix what you should have done right in the first place, you won't stay in business long"
There is no way any non-trivial (i.e. real-world) software can be delivered completely bug-free. Maybe not even the specification is complete and bug-free. Operating systems and other interfaces change.
So a developer of bespoke software should shoulder all that risk ? That is not reasonable. Even Microsoft, who make billions every quarter in profits will EOL their product. You are saying they should fix problems for ever. Nobody is doing that.
I beg to differ. Microsoft always seems to be hiring.
Once the client signs-off on it, they accept the bugs as well as the features.
Bugs? There are no bugs! only undocumented features.
This is what a maintenance contract is about. Generally there are three parts to a maintenance contract. One is that you will charge a set fee for any changes or new work (potentially with a yearly retainer to cover your costs in being ready to do this work) and the other part is that for every year that they pay a fee you will fix any bugs. Often this second part has a year or so included with the initial work.
The first part of the contract might also cover preventative maintenance such as checking to see that the hardware is functioning, backups are being done, and that nobody is messing with the software.
Where you really need to cover your ass is in two areas. One is their losses. You can't be responsible for them. If the system is down for 30 minutes during a critical sales pitch they could argue that you just cost them a billion dollars. The other is if they ruin things somehow. If they have someone else mess with the system or they don't do backups, or use sub standard hardware then you need to be able to wash your hands.
The third critical part is the breakup clauses. If they become a pain in the ass or your company just morphs into something where the old clients are a distraction you need to be able to walk away. The best way (and something they should insist upon) is the source and documentation they would need for them to be able to hand the contract over to someone new in a second. Personally I would refuse to deal with a company that didn't provide this.
But most of all I would never in a million years commit myself to a company like that. Not just because it would be stupid but also any company that would insist on something so douchey is going to be the biggest bunch of scum to deal with. I could see them insisting that new work and upgrades come under the purview of fixes. "Oh we have moved to a new OS and your software broke." I tried accessing it with an iPad 9 but they don't use HTML anymore so you need to fix that." Then knowing they have you over a barrel they would say, "If you just make it compatible with our new database, OS, and mobile devices we will let you out of the contract in 2 years."
Lastly maintenance is where many companies make the big bucks. I witnessed where a letter was capitalized and the company billed $1,200. This was in a scripted environment and implemented by a single developer with no complicated QA process. He just logged in directly and VI'd the script.
Presumably since you ask that means one of two things: either a) you are still at the negotiation stage before any work is done, or b) the main work is finished and the issue just arose.
If you are still at the negotiation stage, then take the hint from the other highly experienced people writing here: "lifetime support" will actually mean, literally, your lifetime. Do not agree to it. If they are concerned about bugs in the final product, then sit down and draft a "Working State Spec" that defines exactly when the software is 'working'. This must be TESTABLE.
If b) is the case, then you are in a difficult situation. One that probably calls for top management in your company to know all about it. What you SHOULD imo do is: consult lawyers, then go to your customer (don't mention the lawyers yet) and say that you can offer X months for free and then hourly paid support, and if they are unhappy about that they will have to sue you.
I'm pretty sure there's precedent about IT contract work that sets out exactly what it means when a product is "completed". You will basically need to bring it to that state (ask your lawyers what that is) and suck up the cost of it yourself. But at least you will not be stuck with a legally binding agreement saying that you will support it forever.
I am going to go with option c...
find a better software company.
I understand that mistakes happen, I have seen it and done it.
But what I dont understand is the inability for a software company to fix a functional bug.
This means, an issue that is in the system, when certain things happen.
As far as your testing analogy, that is on the software company, what they charge should reflect that. That is not the job of the consumer to consider
I have to chime in here because I feel like many of the comments have missed what this is in .."real world" programming: A Sales Opportunity.
It is inevitable that after a while, your client is going to want new features. If you offer a low rate for bug fixes, or offer a certain # of hours on bug fixes after the original term, you'll keep the channels of communications open with the client; rather than them forgetting about you.
So, you can act altruistic and offer some amount of free bug fixes..but use the requests for those bug fixes as an opportunity to suggest new functionality/features, or make changes outside of that realm that translate to billable work.
If you have a proper consulting agreement, any changes outside of bug fixes will already be in scope as a billable activity, so you should be able to bill for that time accordingly.
I find that keeping lines of communications open with clients after projects has done causes new projects to happen and is a great rainmaker. I think what seems like their thick-headedness is actually an opportunity for you to get more business out of them.
As for this client, you're probably not obligated to anything that's not in writing (IANAL, talk to one.) The "Get it in writing" sword cuts both ways. Tell him you're going to review the support terms in the original contract. Whoops, couldn't find any. Then offer to negotiate some.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
My current employer writes its contracts so that clients who pay an annual support fee get bug fixes for free but they still have to pay for implementation costs for upgrading to the version with the bug fix. It's the software that's free, not the hours it takes us to get them upgraded. That's one way to do things.
Another way is that software is delivered as is and the support contracts specifies the rate at which bugfixes will be delivered if bugs are reported.
Another way is that some bug fixes will be free because of their magnitude but that others will be in future releases of the software that must be purchased.
Basically there is more than one way to do it. But, like other commenters have noted, if you've already sold the software and are now negotiating how to handle bug fixes, it may be too late. These sorts of things should be negotiated up front as part of the initial contract. If you didn't, then you probably need a competent IP lawyer with experience in the IT sector to tell you the relevant case law and commercial code concerning liability for software with defects.
In other words, it's the typical balance between speed (of development)/cost/quality. Pick two.
You want it fast and cheap? You'll get bugs. You want quality and fast? It's gonna cost (to hire additional programmers). You willing to pay for quality? It's gonna take time to do right.
That's really what it breaks down to.
I work in the mainframe software area and standard there is 1 year of support included in the price, then maintenance deals are also written are usually between 3 and 7 years for usually 15% of the price of the software. Though those deals are high convoluted now since you dont sell individual programs to customers any more but rather a packaged deal.
In terms of legacy support, that isnt really done either. Usually 3 major versions of a software are supported, meaning fixes are created for them regularly. That usually means a 5 year life cycle for a release. Fixes for problems once a version leaves support are special maintenance deals that usually cost more.
Though we have sold code as is. Meaning that the client is then responsible for maintaining the program because he has ownership of the code and a full license to do with it what he will. Though there is usually a 3 months period where we work out the bugs with them, but after that the code is theirs and they can fix it.
After the initial period of software problem support of months additional support is at our customary hourly rate of $$$ adjusted annually by no more than 10% from the acceptance date of the contracted work. A prepaid retainer of $$$2 may be paid for a yearly support contract. The $$$2 amount may be adjusted downwards annually to reflect past performance and upwards for inflation.
Then make $$$2 be about 20% of the contracts value.
I have been nickel and dime'd to death by major industry players who feel they are entitled to infinite support and even "small changes" for free. Sometimes a small enough matter (or occasionally a big one time one) is done as "good will", but don't get sucked into free support forever unless you build that into your contracts price. As in for contracts under a years duration quote a price at least 20 times your cost if you are so foolish as to include lifetime support for no additional cost.
- Tjp
I am in wallow with my inner money grubbing capitalistic pig. ... Oink!
My first reaction was, depends on how crappy your coders are? Meaning are you coding to industry standards? if so then it should be spelled out in the contract. If not then you breached your implied warranty and should fix the problems forever.
not really, because if you get a kid you can always put it up for adoption, so no it's nothing like having sex with out a condom.
This is a Mac, what you have there is an embarrassment to your fellow computer users.
People would be out of business if this was promised.
Warrangy of 30-60 days is normal. This should all be written down in the SOW (statement of work) and/or T&C (terms & conditions).
Including how things are reviewed and classified as a defect/bug. Changes to infrastructure including OS and DB are not included, even if that breaks your program/process.
And here is the biggee... Once the client starts making changes, all bets are off. I don't fix anything under warranty once the client has their hands on it.
As as first time administrator on an AS/400-based system running RPG code long ago, I was briefly puzzled that our CFO was talking about putting the source code for the software we were to be running into an escrow-like setup. I learned many things from that CFO - in this case, how to protect your company in the case that another company - one that wrote your software for you - goes under. In our case, we were to be given the full source code if the development company tanked. At least that way, they kept their stuff private/proprietary, but we weren't fully shit out of luck if they went out of business.
That same CFO had an incredible eye for liability issues, too, which are another area I always cringe at when I explore various businesses....
I usually include bugfixes for 30 or 60 days. How do you price service contracts? Is it the usual dev rate * number-of-hours-covered-service-per-month? What is typical for a service contract on your dev work?
Because clients like to slip in feature requests as bug requests? And their setup is going to be different from yours?
I am John Hurt.
This is why it's best practice for small software developers to do business with an attorney who offers bulk rates on Delaware corporations and has the reverse merger bit down. You just turn & burn. Several iterations down you can even buy your fully-laundered bankrupt corps back for their "goodwill". Don't they cover this in CS212 still?
Help stamp out iliturcy.
Because no piece of code, beyond that of 'Hello World,' is considered bug free?
I am John Hurt.
I disagree. Microsoft did not provide support as it is being discussed here. Where I worked in the early, relatively bug ridden days of XP, we had large numbers of XP licenses (tens of thousands) and Microsoft Premier support. I reported many bugs and so did many others in our organization. They never fixed a single one of them in response to our reports. They did continue to develop their product, including some bug fixes along the way but my experience was that the bug fixes were not motivated by their support agreements. If I had to hazard a guess, it would be that they were motivated only by the possibility of future sales, but that may just be my cynicism. I was never privy to any of their decision making.
Re: "...should be supported with bug fixes forever, with no further compensation".
Hah! They are the customer, of course they will say that! They want something for nothing and it just isn't going to happen.
Like everything else in the customer relationship, everything can be negotiated. However something for nothing isn't part of the real world. Let them down gently, but firmly. You want repeat business, right?
In the for profit software world I've occupied, "free" bug fixes are only covered if the customer is paying regular maintenance fees. Maintenance is typically ~15-20% of purchase price, so it isn't cheap, and the customers often dislike paying. However many ISV's won't even speak to the customer unless the customer pays maintenance. If the customer tries to game the system by dropping maintenance, then suddenly paying when they discover a bug, the ISV will often penalize them in some manner. The penalty can be something like paying for a year's support, but it costs a 50% premium of annual maintenance to restart the contract.
Please specify where these industry standards can be found.
I'm pretty new at this programming stuff, having only been at it for 30 years and I haven't run across any universal industry standards document yet, so I'm all ears.
Sig Battery depleted. Reverting to safe mode.
Seriously? Are you guys nuts?
Contract Contract Contract
You get mixed up with the wrong customer with a bad contract and you could be out of business before you can blink.
You should have very specific, MEASURABLE deliverables. Things like "Make the interface faster" are not going to fly. What does "faster" really mean?
Your support structure should be very specific. They should be signing off on every single thing in the deliverables. After that your contract should specifically state what's considered a bug and what's considered a scope enhancement. I guarantee you that every single thing they find that isn't exactly what they imagined in their many managerial meetings they are going to consider a "Bug".
"You designed this forum for us, but when we try to attach this 4 Gigabyte file to the post, internet explorer crashes before it can even upload. Clearly this is a bug!"
My company has many types of support contracts and it all depends on the project and who we're working with. The company that built and maintains our website has been supporting it for over 10 years. We have an on-going contract with them, and they basically build or change anything we want, whenever we want. That contract is VERY lucrative for them however. We actually have offices for a few of their employees in our building. I don't even have an office!
Other contracts we have basically state that bugs found that are IN SCOPE are handled, for free, by the vendor for a certain period after we've accepted the product. 2 weeks seem awfully short to me. I doubt we'd ever except that. Usually it's more like 90 days. We're a relatively big vendor and pay a premium for what we want though... so we get what we want or don't do business with you. After that 90 days we have a set hourly rate that the vendor will charge us, for another set period of time. Say 1 to 2 years. Usually that hourly rate is somewhere in the $100-$200/hr range.
If you don't have good, solid contracts to base your work on, you are either going to get screwed, or get a name for yourself for screwing your customers. Or worse, sued into oblivion when you have a disagreement with the wrong customer that just happened to a have a whole floor full of bored lawyers just waiting for you to screw up.
Tell them you'll support them if they hook you up with their dealer.
Thats about two years on average. And its in the purchase and maintenance contracts too.
Indeed. However, with your typical client for websites, the work is being done for cut-rate prices. *shrugs* I consider it the airline model (where everything costs extra)-> you want the super-cheap website, the tech support is going to cost you.
Now, people might get us wrong; see, from their standpoint, they're paying someone good money to do magic. Right? Except the plumber who visited your house a few months ago earned more per hour than we are. As did your car mechanic, when you had that engine work done a few weeks ago. What more, if you've chosen not to go the cookie-cutter CMS route, you're getting a product developed just for you.
A simple, elegant website is quoted at $700, and that's for HTML with some JavaScript thrown in. But that's not what you want for $700; you want a Flash-enhanced PHP/JSP/ASP.NET monstrosity with a dozen hard to code features (i.e. features that require RESEARCH, just to see if it's feasible), that typically costs $15,000+ to code, and several months of back-and-forth before even laying the groundwork. On top of all of this, you will also ask for a discount, since you are putting work our way!
When my spellbooks (code books) cost more than I am going to make off of a job, I seriously question the field I've chosen in life. Which is why I am out of the web development circuit; at the very least, nothing below corporate-level clients, and even then, they're going to pay (but should be fairly happy).
I am John Hurt.
Whether the client plans to do more business with you in the future or not may be a factor. You might make a deal where "Your payments for developed software includes 1 year free maintenance to start after implementation, unless you sign up for a longer maintenance contract, or you negotiate new terms with us after 1 year"; you might make a deal where "Any new software project or major upgrade you commission us to perform, will renew your support for existing work, when we receive payment for a certain minimum amount of billable time, and then 1 year after completed implementation of the new project.".
If this was a one-time custom software design job, then provide your client with the source code, provide a contract or a "warranty" for a reasonable duration that includes bugfixes, and a certain number of minor feature additions they may request, then beyond that bill based on your costs; If you are a small shop doing custom work , you possibly can't afford to lose a positive referral and future business based on your mistakes; bugs are your mistakes, and you owe it to the customer to make amends for your errors..
However, Every Warranty Has an Expiration Date; if your customer doesn't discover the issue within 6 months, then it's probably reasonable that you didn't discover the issue either, they are just as much at fault for not finding an issue. The companies that offer Lifetime warranties are very big companies mass-producing very simple products that are inexpensive to replace, and Lifetime warranties generally aren't valid once the product goes End of Production / End of Sale anyways.
If your client isn't agreeable to the terms your business needs, eg your customer is just too unreasonable, and you can't come to an arrangement -- don't leave your customer high and dry, either provide them with the source code, or agree to provide source code to a third party software firm they will contract for maintenance (under appropriate NDAs of course).
Obviously your customer is in the wrong expecting perpetual development work for free, unless you have an ongoing business relationship that is mutually beneficial.
A restaurant may post a "Free Refills" sign by a drink fountain. That doesn't mean it's reasonable for you to bring your glass home with you, and come by every morning expecting free refills of the drink you bought last year, for the rest of your life.
Now if you paid $50 for that 8oz soda, perhaps it would be reasonable to expect free refills for a few days, but still, not forever.
No, it is just like sex without a condom. dumping your kid on someone else == refusing to support your garbage code (which forces someone else to fix/support it).
You have acceptance testing. Once the client signs off, it is theirs, warts and all.
Whether or not they get source code should be in your development contract.
Support after formal acceptance is covered by a separate support contract.
Learning HOW to think is more important than learning WHAT to think.
As long as the support contract is still in effect.
Dealing with people that will try to nickel and dime you is no way to make a living.
Let some other chump provide them with "service". Spend your time finding decent clients.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
Please stop telling the OP to get a contract. Nowhere in the post is there a mention of legal issues or contracts or lack thereof. S/he is specifically asking for the "industry convention" on support terms for custom software - not how to enforce said terms. I too am very interested in the answer to the question. So unless you answer is 30 days, 60 days, 3.14 days, 5 bugs, 13.135 hours or anything else of relevance, please don't pollute the topic, I'd like to be able to see the actual answers.
Two months of fixes and tweaks is reasonable. I generally allow for that also... however if something comes up, even years later that I consider a negligent defect I fix for free and don't look back. One recent example that came up is bug for not escaping special characters in a XML text field.
10 print "Helo World"
Ha! I can fuck up even that!
Too late now, but how it should be, is that you fix bugs until specification is met and the product is tested and accepted.
Any further bugs, changes, requests should be paid. Sure you can get lifetime warranty on a knife or something simple. Not software. Even software giants' products reach their end of life and thus the end of support.
If you promised life-long fixes, well sir .. you fsck'd it up really bad..
Every piece of software I have seen in the medical field is 1 year support and maintenance and a maintenence and support contract for a fee after that. If they drop support let them know that if they pick it up again in the future then there is a retroactive re-up fee. This covers your costs of having to relearn dead projects. There is no company in the world that supports software infinitely however I've never seen a 2 month span either.
Sorry for typos, slash dot on an android sucks.
That's what we do. For 20% of full cost per year we're on hand to provide support for our product. Often you don't have to do much more than hand hold, but clients love the security of knowing they have the expertise of the developer at their disposal.
I swear to God...I swear to God! That is NOT how you treat your human!
I do bug repair for a year, minor tweaks and cosmetic changes for a year, reasonable functionality adjustments for six months, and non-major aesthetic changes for six months. But it's different in my world because I don't go through a spec first at all. I basically do that effort after the build instead of before.
In your case, I'd say that two months isn't too short a period for real world testing, but it definitely requires the client to actually do their real-world testing directly. If you don't intend to pressure them into doing it immediately, but to allow it to come up naturally instead (which I'm not sure is any better, and I can see how it's worse) I'd say that up to four months is perfectly reasonable for a client paying your full price.
I'm surprised you don't know these. I learned the standards when I first started programming. For example:
Have these changed?
If you say "Give me a web site in two weeks", I'm going to develop as much functionality balanced with as much quality as possible. There is no such thing as bug-free software. It costs money to QA software and find bugs. And lets face it, even with all the automated unit/integration/smoke/exploratory testing, there will STILL be bugs revealed after a production deployment.
Quality costs money, and it ought to be part of the maintenance cost plan.
I write into my contracts: 1/3 due up front (agreement of the spec). 1/3 due at delivery. 1/3 due at acceptance. Acceptance is either when they sign off, or one week after delivery of product or delivery of the fix of the last bug determined between delivery and acceptance. Anything after acceptance is billable. Any "bug" that does not match the initial spec is not a bug, but rather additional work to be billed. The original spec is initialed on all pages by them Any changes that they ask for and I agree to during the course of the product being developed are added to an amended spec, sometimes gratis, sometimes at an additional cost. It is a pain, but it is the only way that these things go smoothly.
Always good to have a written agreement and while you're at it simply charge by the hour. Good enough for lawyers and accountants.
Anyone who thinks code beyond "Hello World" can be not only written bug-free but handle the abuse a client will put it through obviously never got past "Hello World".
I work at a very large publisher that uses contractors, and our SOW's generally call for 90-days of warranty support. While not clearly defined, I believe that the warranty should cover issues within the initial set of requirements.
Library upgrades are a grey area.
New features or things that break because we've changed our systems I do not ask for that support.
1. You have an ongoing business relationship with the clients and can expect plenty of new business from them in the future, or
2. They pay you for a support contract.
Or, depending on the level and severity of the support services required, you might do it just for the "goodwill" but if they're being pricks about it, fsck 'em.
My company develops several products (Hardware and Software)
We offer lifetime free updates for all of our products. We've never charged for an update. There are of course newer functions that might not work on older hardware. So far, all systems we've sold since 2007 run our latest firmware flawlessly.
Of course, that doesn't hold true for custom-made software. If you are actively developing a product, it doesn't hurt to give away updates for free for existing customers, but giving lifetime free support for a custom-made product is economically unfeasible.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
As long as the contract specifies. If the contract doesn't specify, you're a dufus and should make sure that it does from now on. For the clients with which you are a dufus, you must weigh the potential loss of good will against the expense of billable hours. That's a PiTA, which is why you specify support in the contract. Duh!
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Thats a BS excuse though - if you wrote crappy code, you should fix it. I think its reasonable to say 12 months.
You have to support it for whatever it says in the contract.
You DO have a contract, right?
..........or until you no longer want them as a customer. If you stop support on something they paid you to write, you have lost them most likely.
Sure you are in the right legally, but is it worth the lost business?
---- Booth was a patriot ----
It's sad that you have to be a lawyer (or pay one) to do almost any kind of business nowadays.
I'll try to repro any bug; at that point it's often easy to spot and fix and I can comp it if there's not too much work involved. If it's harder but it's a stupid bug that I missed, I'd still be inclined to just fix it, even if they took 6 months to find it.
Unfortunately, doing that amounts (in many clients' eyes) to promising to fix anything they ever find for free: there's just no way to tell someone that one bug was (in my sole opinion!) my bad and therefore free but another is going to cost them. It's less trouble to just stick to the contract unless you know them really well.
On the other hand, if they want something else down the road and we have a decent relationship, I might deduct the cost of their bug, and tell them why. At that point, it can look like a good thing without setting a precedent.
Both sides know that there is no such thing as bug free software. Never has been. Never will be. Expectations to the contrary are not reasonable, and never have been. Expectations of indentured servitude went out with the 13th amendment, and no contract can bring that back.
Expectations of being sued into indentured servitude, however, did not go out with the 13th (nor did indentured, only involuntary, servitude)
I'm a consultant - I convert gibberish into cash-flow.
When I left Tymshare (as an employee back in 1978) I told them they could call for help, but that the amount I would charge was based on who had been working on (i.e. f*cking with) the code since I left. I quoted $50/hour (remember, 1978), but there was one person who was a six-dimensional train wreck, and I said if I had to fix any of his bugs it would be $10/line of code.
Sure enough, about 9 months later they called. It was Train Wreak Guy® and it cost them about $30,000 for 3 days of my time to de-f*ck the database code.
Because I had told them ahead of time what it would cost there was no argument. I got my check and they were happy.
Why would you stick a tongue into your cheek? It sounds mighty uncomfortable.
I agree. Awesome time to not have mod points.
Perhaps, but only if absolutely nothing changes on the server systems or client computers for those 12 months.
IBM??? Ha ha ha ha ha. You ever use any of the Rational products? Or god forbid BuildForge....that behemoth of shit is something real special!
No I didn't. I've never signed any sort of "acceptance" document that releases the vendor from liability for bug fixes. I only sign off on features being implemented. I'm not an idiot, the lawyers review everything before I sign.
As a sometimes project manager I've never signed off on any document that releases a vendor from bug fixes. I will only acknowledge feature implementation. The lawyers review anything you want us to sign. If your product proves to be demonstrably defective at any time, you're going to own it and that's non-negotiable. If you can't stand behind your work, please don't bid. It's not like we've ever hurt for bids on any projects from quality vendors.
All you guys posting here are more evil than Microsoft.
http://support.microsoft.com/gp/profsup/en-au
When Microsoft stops providing free security fixes for Windows 95 in 2010, you all call them evil, but looks like in your own businesses, free support ends when the customer signs the cheque for the original software.
French kiss.......
Q.E.D.
Anyone who thinks this way has obviously never written FAA or FDA (medical) certified software.
I believe that it's a lawyer and not a developer that needs to be consulted in this case as there are legal precedents. Just try googling for uniform commercial code software development
E-mail notification of newly discovered bugs known to be application-wide for all should be free and ongoing. Maybe after a time, say one year, a yearly subscription for clients to access otherwise free downloads for fixes should be standard and cheap.
Ask your client to try that the next time he buys a car!
and start a new one next time, with warranty period.......period
For a time, I worked as an Infrastructure/Purchasing Manager for a mid-sized government department. During that time, I was responsible for the oversight of the purchase of several software packages - ranging from PC-based client/server packages through to mid-range AS/400 packages. Our general rule of thumb (and I emphasise that it was nothing more than that) was to pay around 10-15% of the original purchase price each year as a general maintenancce fee. If this included a minimal level of desktop support, we were winners. If it only included bug-fixes, it was tolerable.
Software like Microsoft's that is licensed or purchased does typically have an expectation of free bug fixes from customers, but unless it's in writing the customer should be prepared for the possibility that the company will refuse to fix it, particularly if it's old.
And other software that is licensed or purchased, such as AIX or Oracle, you have to buy the current version to get support and bug fixes. You buy a version, it says supported until $date, and after $date there are no more patches, regardless whether there are still bugs, if you want your bug fixed, upgrade your license and install the new version, which is valid until $new_date.
Bug fixes aren't an automatic deal in shrinkwrapped software, it just happens to be something Microsoft does for your convenience.
And practically, the only obvious changes in new versions of AIX are newer bug fixes, performance enhancements and support for new hardware.
... in three computer degrees the most useful course I've ever taken was Business Law.
Microsoft's official license details that the software is sold "as is" without any warranty, not even the implied warranty of merchantability or fitness for any purpose. So in spite of people making claims about using them so that they have someone to 'choke', that's just a bullshit lie. Even the 'biggest customer' basically has no recourse. Likewise, the software is licensed, not sold, so that you can run a copy of it, but not resell it. You can't even resell your license. First sale doctrine and consumer ownership got really screwed by them. In custom jobs, its normal to develop to specifications, with clear goals, targets, deadlines and performance. There are payment milestones, occasionally incentive payments, and usually a development/bug-fix cutoff date. Since these things always take on a life of their own, the requirements list changes dynamically, so small extras can get added after the official "delivery". Likewise, cost-free bug fixes beyond the acceptance delivery usually run out within a month or so (and likewise, documentation/training). After that, its on a cost+ basis. Major changes / alterations outside of the scope of the main project usually means project II, with its own goals, dates, etc. Don't ever get into something where they want fixes forever, or changes forever, for free. It quickly turns into a cross between fealty and slavery.
10 days. I'm not joking. I saw that in a contract from a HUGE consulting firm (A..........e) that bugs reported within the first 10 days after delivery would be "addressed", if they were agreed to be part of the functionality of the delivered software. Basically, any change to the environment - OS, patches, programs voided the warranty. This was custom built, installed, configured code. It was also under nearly constant development with deployments twice a year on our systems.
For a website, I'd say that 60 days is more than reasonable, but there needs to be a clause to that effect in the contract.
For desktop software, support terms are different. Most non-mass-market software that I've seen made it clear that 1 yr was it, but allowed users to install newer versions of the code on the same major level for free. This is for software with fewer than 10,000 total users world-wide. A pretty limited stock picking/tracking/analysis program.
Seems that the more you charge, the less free support there is.
My standard policy is "bug fixes indefinitely", modifications or edits are at standard hourly rates. Of course most of my projects have been very small scope and thus very few bugs.
The problem is you and everyone else is not willing to pay what it actually costs to create bug free code. The space shuttle avionics code was one of the few cases where it was necessary and possible to pay that kind of price. From http://history.nasa.gov/sts1/pages/computer.html:
The result achieved by the 300 IBM programmers, analysts, engineers, and subcontractors was impressive. An analysis accomplished after the Challenger accident showed that the IBM-developed PASS software had a latent defect rate of just 0.11 errors per 1,000 lines of code—for all intents and purposes, it was considered error-free. But this remarkable achievement did not come easily or cheap. In an industry where the average line of code cost the government (at the time of the report) approximately $50 (written, documented, and tested), the Primary Avionics System Software cost NASA slightly over $1,000 per line. A total of $500 million was paid to IBM for the initial development and support of PASS.
When you are ready to pay 20 times the going rate, you may expect (nearly) bug free code. Or you can pay the going rate and the relatively modest cost for fixes.
Whether there is a legal duty to repair bugs depends on particular facts and controlling law in the particular jurisdiction. Getting a lawyer involved before entering into agreements to deliver a work for hire is important. Ideally, a lawyer would help you develop an agreement form that can be recycled in other sales contracts.
But speaking generally, where a work for hire has serious defects that render the product unsuitable for the intended purpose, the person who sold the work is obligated to repair the defects under laws governing liability for defective products (tort law) and under the implied warranty of suitability for the intended purpose that cannot be disclaimed in at least most U.S. jurisdictions (contract law). Courts tend to favor the purchaser of defective products, particularly in the case of an unsophisticated purchaser and latent defects that do not manifest before payment for the product. E.g., you pay a contractor to build your house and five years later the foundations crumble to dust or a fire started by defective wiring destroys the house. The law generally provides a remedy in such situations.
The customer's position in the particular situation under discussion is likely based on such precepts. There are also affirmative defenses to such claims, but I would recommend in this situation that you consult a lawyer with expertise in this area. You might also consider repairing the bugs in the meantime with the written understanding that who pays for the work will be sorted out later. If you do not, the customer may hire someone else to make the repairs, then come after you for the cost, which because of the subsequent contract's lack of experience with your code will necessarily be far higher than your own expense to repair.
Paul E. "Marbux" Merrell, J.D.
-- retired lawyer
>> I'm not an idiot
If you insist...
You should support it for free as long as stipulated in the contract. If it doesn't say anything about free support, there is no free support. Under no circumstances should you provide "free support forever" without an obscene amount of money up front.
Move sig!
Ask your lawyer for details.
You just do exactly what it says in the support contract. You did sign a support contract with the customer, right? You don't sell our service for lump sum X, but for lump sum less than X, plus monthly or yearly fee Y. It's a steady source of income, and repeat business, and protect both you and the customer from having to sue each other.
Without such a contract, the customer might expect you to support the product free of charge for ever, or sue you if the product has flaws that weren't in the sales contract. They'll probably win too.
A clear contact would have made the question a lot simpler, in any job like this you ether hand over the finished 'work' with some sort of support statement. It may be just bug-fixes for a set period, or possibly a pay-as-you-go system, or a set support time frame. If you or your customer failed to include this in a contact, then I suggest that you gather all of your notes and emails relating to the job and look for a time where support was mentioned, and seek legal advice NOW!. A simple letter to the customer may sort this matter out, or you could be like a few companies and offer unlimited support for a fee, which grows and grows. You may also charge for after hours support, travel, extra penalties for problems caused by unauthorised/unsupported upgrades, etc.
There was an unknown error in the submission.
If there is no economic or contractual incentive to fix software then don't fix it.
Not entirely true. NASA, I believe, have a pretty good crack at 100% bug-free software.
So when quoting your client, make sure you quote in the same ballpark as a fifty-year space programme that's meant to put a man on the moon, send a whacking great telescope into orbit and make regular trips to maintain that telescope, get a robot to Mars and report findings back to Earth.
It sounds like you forgot to get a contract signed that details how delivery and support are supposed to work. If that is the case, three comments:
- First, for future work, get a standard contract worked out. There are plenty of examples on the internet. Pay for a couple of hours of an attorney's time to check whatever you come up with. Contracts are essential, even between people who get along well, simply because memories of what you agreed to may differ after several months. Prevent misunderstandings, always use a contract.
- Option 1 for your current client (the one with no clear support contract). If the client isn't hostile, treat it as a sales opportunity. Explain what is standard in the software world (support for a fee), come to some compromise that winds up with you selling a long-term support contract.
- Option 2 for your current client, if they are hostile. Depending on where you live, laws vary, but afaik all countries have warranty laws that can also apply to software. In the absence of a contract, you may be on the hook for support for the duration of the minimum guarantee period - but no longer than than. The customer may also have the right (if you software really sucks), to return the software for a full refund - in which case, of course, you have the right to verify that they are no longer using it. You would really need to check with a lawyer who knows your local laws.
Enjoy life! This is not a dress rehearsal.
'Forever' option. Charge enough extra that the risk-free interest rate pays for the minimal support they might need, forever. About $700,000 ought to do it.
I charge people to run yum -y update.
We should get together for drinks!
This question just highlights how poor Software expectations and work is done. If a processor released by Intel has a bug, they have recalls and get sued, but SW is EXPECTED to have bugs and support is by some predetermined time or compensation. If you look at this from a product point of view, then it would be in the best interest of the party making the SW to create bugs to have to fix later for more money.
I think forever is more than reasonable if you didn't meet the original requirements. If you did, then additional requirements require additional work, which requires additional pay. All the requirements I've ever seen though don't specify number of expected bugs.
Yes!
Any support on your product beyond the end-of-support date for a product needed to perform this support should be on a best effort basis, never on result commitment basis.
Also consider increasing your hourly rate by 10% for each year beyond the end-of-support date of the products you use - this encourages your client to buy an upgrade to a new version of your product, build with current tools.
The duration, if specified, should be stated clearly on the contracts, or it'd be none.
Sometimes it's one year, but usually it's none because the clients are supposed to pay annually to add extra functions -- including patches for all the bugs they fail to detect when they receive the final product.
They shall have one year after delivery, then they shall need a support agreement.
If you discover that you have a bad agreement you can always as a supplier liquidate the company and start a new since the customer had an agreement with the liquidated company it's no longer valid.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
These days, there is a growing issue of applications written for Windows XP that don't work under Vista or Windows 7. While Windows XP mode is fine for some things, it doesn't handle EVERYTHING, and won't take full advantage of the power of newer computers. So, you see these old apps needing to get updated, and some clients expect the original developer to just make a new version available for free. With Windows 8 this year, the compatibility issue will become even more of an issue here, so people want new versions of the software their company paid for.
"My client says any software/website we develop for them should be supported with bug fixes forever, with no further compensation."
You need to set him straight. Support is always after the fact. Support should always be charged. If you wish to wave support fees and off patches as gratis for a year or whatever, that's fine, but you need to make it clear support is done so for a support fee - annual or per incidence. Any other option is begging the client to screw you over royally. The world just doesn't work that way - except for suckers who accept such bad deals and dickheads who insist of pushing such deals through on the other side.
C NO DONT USE COLUMNS 73-80 00000010
C THEY ARE RESERVED FOR SEQUENCE NUMBERS 00000020
Of course, your clients can choose to contract services from people that gives them some extra "no charge" guarantee time - but this guys will just charge these extra months, disguised, on the bill anyway - so you can compete with price.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Don't know where you get your 80 from, but my punch cards only had 72 usable columns..
(Yes. IBM Mainframe..)
Coz eternity my friend, is a long *ing time.
Sorry to reply to own post, but of course, the important point to take away from the above is that sometimes you have to be willing and OK to let some crappy customers go. It's fine. You don't have to win every customer. Let them grumble a while, and then find someone else to abuse. Usually, they aren't going to change --- because we are talking about the personalities of individuals --- even if you painstakingly manage to cover every possible little detail in some contract, they will usually still be unreasonable bastards that end up annoying you and trying to make unreasonable demands. If you want to live long and not end up having a stroke, let them go.
I've found (having been there) that most reasonable customers are willing to be reasonable and fair if you have a frank discussion with them about what is fair. For example, and responding to the OP "lucky4udanny" now: If your original contract covered only 3 months of labor for initial development but didn't cover much for bugfixes, and you have already spent 3 months working, and this stuff wasn't covered properly in the contract, then an email to the customer explaining that you would effectively be working for free and that it would not be fair to do so, is reasonable. A reasonable customer would usually understand such an approach. Unreasonable customers will then expose their true colors further. If you were paid for four months worth of labor, but have only worked three, then it might be fair to say some additional work is still 'covered'.
One thing I learned from the GoDaddy guy's videos, "The customer is not always right, but the customer is always the customer". That is very true.
he can claim what ever he wants,
if he wants "forever" he needs to know that you can ask
1) never update the os
2) understand that what is not in specification, is not supported of fixed.
3) he will be charged if the source of the error , is not on the distributed code fault.
the meaning of his idea, we have specification, if you don't give me what in the specification, ill give you a chance to fix it, or ill sue you for selling defected good.
things that are not in the specification, are not fixed,
example, windows exploit of ini file,
you can dump what ever you want before the first section start, even code, even compiled code, the autorun.ini parser doesn't care.
Just follow what the large companies do. Come up wth a "new version" of the software and then say you will stop supporting the old one in....... Works for windows!!!!! try getting support updates for windows 95!!!!
Even NASA's methods aren't 100% bug-free. They're probably some large number of nines - 99.99999% bug-free, maybe - but just as 100% uptime is impossible, so is zero-bug status.
And NASA's methods are *crazy*. Take one program. Run it on three different computers, connected by a simple voting circuit. That way, if there's a transient hardware error, it has to affect two of them simultaneously.
Now take the specs for that program, and hand them to three different teams. Do not allow them to share code, or even really communicate with each other. Run all three implementations on the above separate computers, so that any bug has to be present in multiple implementations in order to affect anything.
Now take the whole system, and spend about ten times as long in testing as you do in production usage. Have the code audited line-by-line by experts.
And even after all that, you can still have bugs in the specifications. Say, one module outputting in metric when it's passing data to a module that reads in imperial.
If they want bugs to be fixed that you didn't have time to fix during developement,
it implies that you knew the bugs were there, and chose to not fix them (for whatever reason) before selling the software to clients, presumably so you could charge them even more money down the road to fix the problems you purposefully left behind. IMO, that is damn-near-if-not fraud, and definitely not the sort of business practice
Car analogy: A mechanic installs a new water pump, but knowingly leaves off the clamps that keep the hoses attached. Do you really think you, the client,. should be charged extra for the mechanic to fix what he should have done right in the first place? If so, I have a bridge in NY state I'll sell you for a song.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
... and definitely not the sort of business practice
... strike practice...
Append: "I want to give my money to."
Much better.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
Officially, you want it in the contract that support past a certain date is billable. If they want a later date, you can charge more for that. Work all that out ahead of time, in writing, before you do any work on the project.
However, there are some cases wherein you ought to "forget" to bill them. Significant security flaws are one good example of this. Bugs that case significant data loss are another. Your programmers should be instructed to just fix those kinds of mistakes and not bother the billing department about them, and your customer service people should be apologizing to the client for their inconvenience. This is basic "implied warranty" stuff. It may technically be legally possible to disclaim it, but that's unethical and also bad for business.
Cut that out, or I will ship you to Norilsk in a box.
... and suggest that if your contract didn't define its completion, as in a sign-off on deliverables, you have a sticky wicket. Otherwise, your liability to warrant your product is probably defined under commercial law in your jurisdiction. For instance, thirty or ninety days and one year are common terms for such responsibility.
You should only support major bugs. If the client wasn't clear on what they wanted then it's not your problem. Only offer them a free fix on a major issue and all other issues they have to pay for.
Support terms are negotiated on a per-contract basis. Some companies or firms have boilerplate or "standard" contracts that they use to define the terms, but they're company-standard at best.
If some company demanded perpetual free support, my answer would be simple:
Talk to my lawyer.
There can be no "reasonable" negotiations when the customer's position is to get work for free. That's not reasonable, it's not sustainable, and it's never been part of software development anywhere I've worked in 30+ years.
You do not have a customer. You have a leech.
I do not fail; I succeed at finding out what does not work.
The problem is the definition of a "functional bug".
If the client changes the Operating System (e.g., winXp to Vista) and the software stop working, is that a functional bug?
What if the client, after using the software for years (say 10+), informs you that the fourth option on a dropdown should have pre-filled in some other option and thus is a bug (they don't use that option much, testing didn't find it, and there is just one line in a 50 page specification document that mentions this?) At this point of time you no longer have the dev environment available even? e.g., Development was done with Visual C++ 1.0 and you no longer have hardware of OS's to run that version? Does this mean you have to pay to have the software converted to use the latest Visual C++? What if you are no longer a Visual C++ dev shop anymore? Who is going to pay for those licenses?
Lots of issues to be worked out, and everything hanging on the definition of two very simple words.....
Women have choices, men have bills. You can't put your child support obligations up for adoption. Even if you could no-one would take them.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
The time they want support times your hourly wage. Let them count for you.
It's theoretically possible to build bug-free software, sure. I can accept that; a theorist has probably even written a proof for it. But not at a price-point anyone's willing to accept, because of the diminishing returns of investing more time and money into the required documentation, test-harnesses, reviews, proofs, etc. Software products that are still actively maintained will, I believe, trend towards being bug-free, as bugs are found during the course of their use.
But releasing early, with bugs, is overall cheaper than trying to find every single one before initial release. Unless it's a mission-critical, one-shot, life-or-death piece of software, pretty much everyone's willing to go with the lower-cost solution of a "happy medium" amount of rigor.
Even NASA's probes have software bugs, despite everyone knowing ahead of time that they may be unable to upload a patch when the antenna accidentally gets turned the wrong direction, or the computer shuts down permanently, and that the whole project depends on it -- it's still worthwhile to take the risk and launch early, without verifying that every single line of code is in some objective way perfect.
Even famously bug-free software, like Knuth's TeX and METAFONT, didn't get that way overnight -- otherwise they wouldn't have had a need for version numbers. But TeX's asymptotic version numbers (after version 3, once it was already pretty stable)? Beyond being cute, they reinforce what I said above: code gets better over time, slowly approaching correctness. Knuth himself once wrote "Beware of bugs in the above code; I have only proved it correct, not tried it."
You can take your theory, and shove it. Oh, also? Plenty of important software IS bug free. Yeah, [citation needed] on that one.
On the other hand....
Forever is a long time. There is no reasonable expectation of forever in any legal contract for goods or services in any
industry I'm aware of. Even contracts for burial plots do not last much more than 200 years.
Soo...what happens in year 201? Do they figure you're finished with it?
braainnnss...
"I love animals! Some are cute, others are tasty, what's not to like?" - Betsy Schroeder, Jeopardy contestant
On the other hand....
Forever is a long time. There is no reasonable expectation of forever in any legal contract for goods or services in any
industry I'm aware of. Even contracts for burial plots do not last much more than 200 years.
Soo...what happens in year 201? Do they figure you're finished with it?
braainnnss...
http://en.wikipedia.org/wiki/Cemetery#Re-use_of_graves
http://www.bbc.co.uk/news/uk-13357909
http://www.spiegel.de/international/germany/0,1518,527134,00.html
Sig Battery depleted. Reverting to safe mode.
On the other hand....
Forever is a long time. There is no reasonable expectation of forever in any legal contract for goods or services in any
industry I'm aware of. Even contracts for burial plots do not last much more than 200 years.
Soo...what happens in year 201? Do they figure you're finished with it?
braainnnss...
http://en.wikipedia.org/wiki/Cemetery#Re-use_of_graves
http://www.bbc.co.uk/news/uk-13357909
http://www.spiegel.de/international/germany/0,1518,527134,00.html
O_O
I was being facetious, but...suddenly my commitment to cremation is a whole lot firmer...
"I love animals! Some are cute, others are tasty, what's not to like?" - Betsy Schroeder, Jeopardy contestant
some comments mentioned windowsXP... I suppose since winXP was (is?) sold to consumers (unlike lucky4udannys software?) and not only to another corporation, microsoft have to fix manufacturing defects (=bugs) within 3 years after they sold the thing (should apply to software too, not only hard things, right?). The consumer have to report the fault within 2 months after they found it though, and after the first half year the consumer have to prove that the fault was there when they bought it (easy for software, not so easy normally). :-)
This law only apply when selling to consumers though, corporations is supposed to have contracts for these things,
and you might have other laws in your country of course
Anyone who thinks code beyond "Hello World" can be not only written bug-free but handle the abuse a client will put it through obviously never got past "Hello World".
What does "Hello World" do when the stdout is redirected to a file, and the hard drive is full?
There's not really a convention on this. Depends on the type of software, whether you can (and will ) reuse any or all of it, making pushing fixes back viable.
Really the only way to get indefinite support is to develop it yourself in house, and that isn't free. You simply have to tell your client that what he wants is not something you're prepared to do, and anyone else offering to do it is almost certainly overshooting their capabilities or lying. You can't retain staff 7 years from now to fix problems some custom piece of code you wrote today, and training someone up that far in the future may not be feasible.
I had a project a few years ago to try and recover some working code from an Apple 2, and last year I was asked to try and find a way to read some CP/M disks. Those problems *can* be solved. But you're looking at a huge amount of time to try and solve them.
The most I would ever commit to a single contract for personally is 5 years. Any more than that and the entire industry could shift and you have no way to be prepared for that. Remember IE6 was replaced in 2006, so that's only 6 years ago, and think of the chaos that causes, and think of the problems with trying to convert code written for IE6 to well... anything else. You're looking at a complete rewrite basically. If you write your code today for regular old Windows 7, well in 5 years windows 9 could be (for all we know) entirely ARM, and only use the metro UI, or the entire industry could have shifted to something other than windows. You don't want to be, and can't risk being on the hook for that. Web services... PHP and sql I would expect to stick around longer than 5 years but languages change and that could be a real pain.
It depends how long and how big the project is, but I would be willing to bake into the price a fixed fee for a year or two after a contract is done without batting an eye. Especially a big contract. Much longer than that and I'd be looking for maintenance in the contract, and as I say, I wouldn't under any circumstances agree to anything more than 5 years out. You can agree to reevaluate the contract in 5 years time if you are so inclined but that's about it.
In short: Indefinite support, no way, no one sane or honest will agree to that. In terms of negotiating actual rates... depends very much on how big the project is. 20 developers for 2 years is very different than 4 for 3 months.
You want an infinitely long support contract? No problem, it will cost an infinite amount of money. Payable in advance.
I think it can be argued that any negative results from doing such a thing would be a bug in your shell, not the application.
Nice theory, but in practice? I have a kid on another continent... and I still get to pay child support.
Try again.
Il n'y a pas de Planet B.
Well I know it's nothing like sex, because there's many different methods to prevent getting a child other than just the act of having sex with out a condom. Also there's a lot of different factors too.
This is a Mac, what you have there is an embarrassment to your fellow computer users.
Here is a link to it on Amazon (Soul of a New Machine, paperback) (and no I do not make a penny for the link, put it for informational purposes...though the cover of my copy (in storage so can not provide it) was very different than the one listed here. If memory serves, it was white primarily with some blue and silver, (found an image, I was close, enjoy) but I am guessing, it was back in the late 1980s or early 1990s when I read it. Actually an enjoyable read.
Also no company will pay anyone or any software development house enough money to check for every possible error, it would not be considered smart business and/or cost effective. Not saying I agree or disagree with that, just stating as a fact based on my experience working both in larger Fortune 100 software development and Small Office Home Office (SOHO) software development.
If you can get paid for it, do it, else that is what a maintenance contract (as many others have pointed out) should be for.