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
" 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.
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.
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.
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!
Why should they pay to fix your mistakes?
Once the client signs-off on it, they accept the bugs as well as the features.
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.
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.
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
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.
Thats a BS excuse though - if you wrote crappy code, you should fix it. I think its reasonable to say 12 months.
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.