Ask Slashdot: How Long Should Devs Support Software Written For Clients? 384
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?"
Too late to be asking.... (Score:5, Insightful)
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.
Re:Too late to be asking.... (Score:5, Informative)
It's probably a good idea to check with a lawyer if there is a legally required support duration and what is covered under it. In this case, he should be happy if there is, because then he tells the client that he'll provide support as legally required and any additional support would have to be negotiated. Don't leave the client hanging if he needs support now and is willing to negotiate a support contract. Be prepared to write off that support in case no contract materializes though and be firm if the client tries to drag this out.
Re:Too late to be asking.... (Score:5, Informative)
Probably a good idea.
And if there isn't I imagine the only answer would be, "We've met the design goals as conveyed to me, and you haven't contracted me to provide infinite support. But you're welcome to make an offer and I'll be happy to work with you from there."
Without being a dick about it, of course. Next time, figure it out ahead of time and everyone signs on the line provided.
Re: (Score:3)
"And if there isn't I imagine the only answer would be"
Well, there were two questions, and two potential answerers so go figure.
My position:
How long the software should be supported for defects?
Forever. Since the software doesn't wear out, any defect was developed there from origin, it's a reasonable expectation that when someone asks for something, it is asking for something without defects, so covering for bugs forever is the only sensible way to respect the contract.
Of course, there's the grey area in r
Re:Too late to be asking.... (Score:5, Insightful)
How long the software should be supported for defects? Forever. Since the software doesn't wear out, any defect was developed there from origin, it's a reasonable expectation that when someone asks for something, it is asking for something without defects, so covering for bugs forever is the only sensible way to respect the contract.
If you have a contract that actually makes you provide free bug fixes forever, then you signed a shitty contract. Software always has defects, this is simply a fact of life. Extremely rare defects, by definition, do not make themselves visible very often. The reason rare defects are not found during testing is precisely because of this. More comprehensive testing does not ensure zero defects -- it only ensures that whatever defects do remain happen exceedingly rarely, or under exceedingly improbable circumstances.
It is quite reasonable, as a client, to expect a software maker to provide bug fixes for software they provide. It is equally reasonable for the software maker to request ongoing payment (commonly called "maintenance") to continue providing these bug fixes indefinitely. Both parties to the contract are making a risk tradeoff when they sign. The client is risking that they will pay a certain amount of money for the software (including the initial development costs and any ongoing maintenance costs) and never actually recoup this expense by using the software. The software maker is risking that they will charge a certain amount for development and maintenance and some defect will arise that will cost more to fix than they are getting paid to fix it.
The two parties hopefully meet in the middle with a price and contract that seems optimal for both.
Just because it's software, doesn't mean you let your eyes glaze over and throw basic economics out the window. Or, for that matter, the basic observation that humans are fundamentally fallible and you can't expect people to magically do things perfectly just because they work in a technical field.
(Another factor in this is that it is actually not risk-free to fix bugs. Fixing bugs necessarily involves changing code. Changing code may introduce yet another defect, or expose a latent one.)
Re:Too late to be asking.... (Score:5, Informative)
Please read "Foundations of Software Testing" to understand that what you are saying is wrong on so many levels.
You should indeed do your best to write the best software you can, but there are enough factors influencing you that you never can be sure your software is bug free.
Re:Too late to be asking.... (Score:4, Insightful)
No you can't. And if you think you can, you're deluded. No non-trivial real-world program has ever been bug-free. Especially not programs large enough to have more than one developer.
Even programs which are *very* carefully specified and written, and tested thoroughly, end up having bugs. These programs cost atleast one order of magnitude more than normal programs, and *still* have bugs.
When the first pentiums had bugs that caused them to do floating-point-division wrong, it wasn't because they where sloppy, or because they where untested. They where tested 3 orders of magnitude more than most comercial software will ever be - and *still* launched buggy.
Given that guaranteed bug-free is unattainable, the right question is what amount of quality-control and testing is worth it. Sometimes it's worth it to spend 10 times the amount in order to get rid of half of the most serious bugs, but often it's not.
Re: (Score:3)
>> Software always has defects, this is simply a fact of life.
> You absolutely can and should write fully functional, properly-tested, bug-free software.
Maybe in the perfect fantasy world you live in, sure.
Back in reality, some of us devs *do* try to write as-much-as-humanly-possible bug-free software. Unfortunately, specs change, and to guarantee 100% code coverage of ALL possible paths would mean you never shipped.
Don't toss the baby out with the bath water just because we *grudgingly* accept th
Re: (Score:3)
You absolutely can and should write fully functional, properly-tested, bug-free software.
Let me guess, you're in management.
Re: (Score:3)
If the parties involved didn't even bother to nail down something as basic as how much support is included in the contract, do you really think anyone bothered to ensure that there were reasonable and unambiguous specifications up front? Who pays to determine what's a bug in the application code (developer's fault), what's a bug in the requirements or user error (customer's fault), or what's a bug in the OS or any third party libraries (someone else's fault)? And once that determination is made, who pays to
Re: (Score:3)
Re: (Score:3)
Microsoft has supported XP for seemingly forever. At no charge (3 major updates and also minor bugfixes - all free). But you're right this Questioner should have a contract somewhere to specify exactly how long the software will be supported. One could argue that "no time specified" means the customer should get no support at all. They should not have signed the contract, if they did not like those terms.
Re: (Score:3)
His situation is reversed. He puts a web app out there, and browsers / technology / other software will constantly be changing around it.
Re:Too late to be asking.... (Score:5, Interesting)
I don't know what his app is, but I look at it this way (and is how I handle something I write):
Is this a bug?
Assuming it is then:
is this something that is obvious code error (i.e. buffer overflow, null pointer, etc.)? I fix it.
Is this something that is behavior not as expected, but is not a code error (logic error), and should have been seen as part of acceptance testing? I charge for the fix.
really simple, and so far I've not had any customers balk.
-nB
Re: (Score:3)
That leaves you open to one problem, the bounds of the system. If you promise unconditional support will you need to re-write your app when Windows 10 breaks it even though the customer isn't asking for any different behaviour.
If you offer support like this, bind it to the system it was designed for. That naturally limits the life of the support contract to the life of the system which may only be a few years.
Re: (Score:3)
When I've got $30B in the bank and a firehose of an income stream, I'll support all my past customers gratis too...
Re:Too late to be asking.... (Score:5, Funny)
Give MS a call, and tell them you found a critical security bug in Windows that you need fixed. Then tell them it's a DEC Alpha with WinNT 4.0 Server. Make sure you record it, I want to hear the laughter. :)
Re:Too late to be asking. (maybe not) (Score:5, Interesting)
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.
Re:Too late to be asking. (maybe not) (Score:5, Insightful)
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)
Best Practice (Score:4, Insightful)
Re:Too late to be asking.... (Score:4, Funny)
As a small company you simply agree that your company will support the software in perpetuity, then disband that company when the support costs hit a pre-determined point, and start a new one with the same people. The liability for the support dies with the old company.
Hey, don't blame me for corporations law.
Re:Too late to be asking For the client too! (Score:5, Informative)
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.
Re:Too late to be asking For the client too! (Score:5, Funny)
I'm surprised you don't know these. I learned the standards when I first started programming. For example:
Have these changed?
Programming is like having sex without a condom... (Score:5, Funny)
...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.
Yeah, But That's Not Really True (Score:5, Interesting)
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.
Never. (Score:5, Insightful)
" 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.
Re: (Score:3)
You have your answer. You charge by the hour for support including bug fixes. Only slaves work for free.
If there is nothing else in the contract then I would say yes, once the client has signed off on it any remaining bugs are billable. Of course then it's easy to dump a bug-ridden piece of shit on the customer, hope they do poor testing and cash in big both on finishing early and getting extra bug fixes. So I wouldn't say "never" is that common, most contracts I've seen have a guarantee period of 1-6 months where bugs are fixed free of charge. But they always make it clear this is a service and obviously it'
Re: (Score:3)
You have your answer. You charge by the hour for support including bug fixes. Only slaves work for free.
It depends. Are you selling the product, or your work? If you're selling the product, you should support it, because if it's buggy, then the client didn't get what they paid for. If you're selling your work, you always charge by the hour no matter what.
In reality, most arrangements of this type are sort of in between, which is why a service agreement is so important. Also, it may depend on how much
3 Months (Score:5, Informative)
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.
Re:3 Months (Score:5, Interesting)
Re:3 Months (Score:4, Interesting)
"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."
You should have a specified "scope of work", describing the deliverable. If the situation changes to the extent that anything lies outside the original scope of work, it costs extra.
I used to work for an engineering company, and that worked for them. Just be sure to specify your scope of work. Then actual bugs that lie inside the scope of work are your responsibility. Anything else is not.
The client is always right (Score:5, Insightful)
Re: (Score:3)
I would provide x amount of time for warranty (say two months) and provide the option to buy into service (monthly fee) that covers feature and security fixes.
The best part of a service model is that you keep contact with the customer and you can up-sell them to the next feature release.
This model does not work as well for all custom work.
For custom x months of warranty plus $x per hour for changes and fixes. Providing them with a lifetime support option is very unpredictable and may scare the customer awa
Re: (Score:3)
No, they'll choose the one that's cheapest and expect you to fulfill the one that makes the most sense.
Clients are asshats. Well ok not ALL of them, but a lot of them certainly are. I can't count the number of times I've gotten a call asking me to fix something immediately as if all I had to do was flip the "fix this bug" switch and had really just been holding out on them for some unknown reason.
Re: (Score:3)
What they expect doesn't really matter (as long as you are willing to lose them as a customer going forward).
If you both sign a contract for given work at a given price, they are obligated to pay the agreed price and you are obligated to do the agreed work, no more, no less. Unless they can prove in court that you didn't fulfill the contract they're pretty much SOL.
Which is really the answer to the article question - there is no "industry convention", the industry convention is to negotiate a contract that
Get it in writting (Score:3)
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!
The key word here is "Support Contract" (Score:3, Insightful)
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.
Depends on the industry (Score:3)
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.
Refer to your original contract (Score:2, Informative)
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
Be careful... (Score:5, Insightful)
Re: (Score:3)
Those things need to be spelled out ahead of time, for a project of any size. If the customer's needs change, that won't be in your written scope of work, and you can point to it as proof.
For small projects, I've been able to point to emails and say, "You didn't specify that anywhere in your instructions." For anything larger, put it in writing more formally.
It can be something as simple as a "Project Description", written by you and sent t
Hmmm... (Score:3)
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.
Support as long as you are paid for it (Score:2)
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.
After accpetance, it's pay-as-you-go (Score:5, Insightful)
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.
Re:After accpetance, it's pay-as-you-go (Score:5, Interesting)
This guy has it right. Deadlines go both ways.
I once had a client where the project manager handling our contract often sat on deliveries for a month or more before looking at them -- and here I am with a three man development team dedicated to this project. Finally we fly down install the production software and train the users. A week later the project manager is fired and nobody looks at the system for over two years until a new manager starts to procure a system and realizes that his predecessor already paid for one. Word gets to the board of directors, and then we get letter threatening.to sue us for not delivering the system.We have no way of proving to them that we flew a team down there and actually did the installation and training, because everybody we trained had subsequently left the organization. But we had the bills we submitted that were paid by the client, which is at least prima facie evidence we did the work.
Now we had the source in our source code control system, but so much time had gone by that just getting all the stuff together needed to build and package the system would have been a pain (this is why you should be using maven, folks, which we weren't at the time). And there is no doubt the system was probably so riddled with bugs that getting it working would have taken much, much more work, but the client made it impossible for us to deliver a quality product. The project manager accepted deliveries with only cursory examination, and so late that it forced us to work on this product intermittently, dropping it and picking it up weeks later.
The lesson is build client responsibilities and support limitations into the contract.
Standing behind your work doesn't mean delivering unlimited support. It means delivering more than you promised. That starts by setting clear limits and conditions on what you are promising.
Really, It Depends (Score:2)
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).
Kernel Panic: Penguins on the bus... (Score:2)
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...
Service Contract (Score:2)
Offer them a service contract.
Staff vs. Contract (Score:2)
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.
Short answer: until the contract expires. (Score:2)
Long answer: as long as they are willing to pay you at a competitive rate.
You sound reasonable (Score:2)
Industry convention (Score:2)
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
Depends... (Score:2)
Latent Defects (Score:4)
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).
A useful car analogy (Score:2)
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 w
Pull an Adobe (Score:2)
Hey, it works for the big dogs...
Maintenance (Score:5, Interesting)
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.
Sales Opportunity, not a problem! (Score:4, Interesting)
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.
What?!?!? (Score:4)
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.
Find a different client (Score:3)
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.
support contract. (Score:3)
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.
Stick to the spec/ (Score:3)
Re: (Score:2)
Re: (Score:3, Insightful)
Re:Your bugs.. your problem (Score:5, Insightful)
>>They didnt code it, you did.
You didn't sign off on the acceptance testing, they did.
Re:Your bugs.. your problem (Score:5, Funny)
Protip: If someone is charging you to use Windows Update, you're getting ripped off.
Re: (Score:3, Interesting)
Re:Your bugs.. your problem (Score:5, Funny)
Re:Your bugs.. your problem (Score:5, Insightful)
Why should they pay to fix your mistakes?
Once the client signs-off on it, they accept the bugs as well as the features.
Re: (Score:2)
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
Re: (Score:3)
Ha! I can fuck up even that!
Ok no problem (Score:2)
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.
Re: (Score:2)
Your analogy doesn't work because software doesn't wear out like most things do.
Re:Ok no problem (Score:5, Insightful)
That's one theory. But when someone decides to keep using the program on a new version of Windows and stuff changes, who gets to support that? Hell, I've seen Windows patches break stuff.
Software does in fact tend to require ongoing maintenance from time to time, just like anything else.
Re: (Score:2)
If your software doesn't work on a new version of Windows, it's either because (1) there was always a bug in your software which didn't manifest itself in the old version of Windows, or (2) something changed in the OS that requires changes in the software to work (for example, for security reasons), or (3) a bug in Windows.
The first case is a bug that always existed in your software, so it doesn't fall under "ongoing maintenance." The second case is a new requirement ("make it work under the new version of
Re:Ok no problem (Score:4)
Figuring out which of those cases hold takes work. Work that may or may not be maintenance. How do you bill?
Re: (Score:2)
Of course it does. It's programmed to fit on a particular machine with a particular OS/tools. These wear out. The media the software sits on degrades, and can occasionally corrupt.
The APIs eventually change. All sorts of things happen, which is the software analog of 'wearing out'.
I'd treat support as a standard warranty deal if nothing was agreed (i.e. it depends on what you paid for it; If I charged you £50k for a wordprocessor, I'd expect to be supporting it for some time; if I charged you
Re: (Score:2)
But not the software.
But not the software.
If your customer wants you to make your software work with new APIs, then that's a new feature which they can be expected to pay for. It's not a bug in your software.
Re:Your bugs.. your problem (Score:5, Insightful)
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.
Re:Your bugs.. your problem (Score:4, Interesting)
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
Re: (Score:2)
Re:Your bugs.. your problem (Score:4, Insightful)
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.
Re: (Score:2)
Why can't it be both?
Re: (Score:2)
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
Re: (Score:3)
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.
Re: (Score:2)
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
Define "bug" (Score:2)
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
Re:Define "bug" (Score:4, Interesting)
nothing that we did was wrong, simply an update of an outside, yet needed (well, not really but you know what I mean) took our entire dev team 3 days to make a fix, thankfully only a few of our major clients were affected.
point being, unless you code everything yourself from binary, you can not depend on no bug ever creeping into play
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
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.)
Re: (Score:2)
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)
Re: (Score:2)
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.
Re: (Score:3)
Problem Exists Between Keyboard and Chair.
Re: (Score:2)
Also: Code 18 - issue is 18" from the screen.
honda doesn't sell me a custom car (Score:2)
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.
Re: (Score:2)
>90% of "bugs" are features, conditions and behaviors not covered by the systems design.
Re: (Score:2)
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.
NDA Required Here (Score:2)
Re: (Score:2)
Apparently your client didn't say the magic word.