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.
" 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.
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.
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.
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."
Why should they pay to fix your mistakes?
Once the client signs-off on it, they accept the bugs as well as the features.
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.
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
I charge people to run Windows Update for them, so I'm getting a kick, etc. ;)
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 prefer PEBKAC.
Problem Exists Between Keyboard and Chair.
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.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
sorry, I forgot to use the "tongue in cheek" font.
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
This happened for a company I once worked for. Microsoft released a windows update to .net back around 2010 that totally bricked our, DOD certified, mission critical systems. (mostly medical, not military) If a backup of the database was run after this .net update, the users would not be able to login to the system. This was accross the board, affected every single system that is out there (10s of thousands)
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
have you seen my sig? there are many others like it but none that are the same
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.
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.
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.
Figuring out which of those cases hold takes work. Work that may or may not be maintenance. How do you bill?
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.
So what your saying is the customer failed to roll out changes to a test environment before releasing to production and got burned. For mission critical systems no less, sound like someone needs to be fired, maybe even a whole team. It wasn't your bug and so your entitled to bill for fixing it, so in answer to the slashdot question - yes bill them for bugs.
Users... the only thing keeping 1st level support from being the bottom feeders.
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?
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....
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.
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.
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.
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
10 print "Helo World"
Ha! I can fuck up even that!
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.
I'm surprised you don't know these. I learned the standards when I first started programming. For example:
Have these changed?
the major clients all have test environments, and there were only a few actually infected systems due to the fact that we tested it and sent a blast out, but the point is still that to the customers who do autoupdates (dentists, lawyers, other "low level" clients) they were hosed for a few days because of an issue that had nothing to do with us. I get your point, and you are correct, but the point I was making was that things outside of a company can cause issues for software, test envionment or not.
have you seen my sig? there are many others like it but none that are the same
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.
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.
I'm not the original AC.
I also crap rainbows and piss liquid gold.
If you're going to take the time to say you have sources you should probably post them.