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?"

Comments

Re:3 Months

[NoNonAlphaCharsHere]

Too right. Been on the receiving end of that "but our processes have changed" phone call. The analogy I use is "Let's say I'm a tailor who makes a suit for you. Now you gain weight and expect me to fix it for free?".

Re:Too late to be asking. (maybe not)

[icebike]

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.

Yeah, But That's Not Really True

[Greyfox]

Back in the 90's (and still to an extent these days) if you were a really bad programmer you'd just screw around for 3-6 months and then change contracting companies, usually getting a $10-$15K raise in the process. Then the next guy would get stuck supporting your crappy job. Case in point, in the late 90's I got picked up on an inventory project that was already late and over-budget. My predecessor had left in a hurry. Upon reviewing her code, I found that, among other things, she had not realized that in C you have to null-terminate your strings. No accountability must have been nice. It's still pretty damn hard to fire a programmer just for sucking, and it's still pretty damn hard to find good programmers even with the economy as bad as it is. Pretty easy to find bad programmers, though.

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....

[networkBoy]

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