Ask Slashdot: How Long Should Devs Support Software Written For Clients? 384
Posted
by
Soulskill
from the just-until-the-next-venus-transit dept.
from the just-until-the-next-venus-transit dept.
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?"
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:Your bugs.. your problem (Score:3, Interesting)
Re:Your bugs.. your problem (Score:0, Interesting)
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.
Re:3 Months (Score:5, Interesting)
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: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: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.
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.
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.
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: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.