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

Too late to be asking....

[jmorris42]

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

[Anonymous Coward]

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

[SomePgmr]

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

Re:Too late to be asking....

[Zaelath]

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

[JWSmythe]

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

[pclminion]

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

[chthon]

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.

Programming is like having sex without a condom...

[Anonymous Coward]

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

Never.

[LWATCDR]

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

3 Months

[Anonymous Coward]

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

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

The client is always right

[Wonko the Sane]

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.

Re:Your bugs.. your problem

[Anonymous Coward]

>>They didnt code it, you did.

You didn't sign off on the acceptance testing, they did.

Be careful...

[billster0808]

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!

Re:Your bugs.. your problem

[MrEricSir]

Why do you think people have/had problems with MS? Because they charge you to fix them.

Protip: If someone is charging you to use Windows Update, you're getting ripped off.

Re:Your bugs.. your problem

[jdastrup]

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:Your bugs.. your problem

[sideslash]

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.

After accpetance, it's pay-as-you-go

[dbc]

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

[hey!]

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.

Re:Ok no problem

[Tridus]

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:Your bugs.. your problem

[radiumsoup]

sorry, I forgot to use the "tongue in cheek" font.

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.

Maintenance

[EmperorOfCanada]

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.

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 For the client too!

[icebike]

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!

[Smallpond]

I'm surprised you don't know these. I learned the standards when I first started programming. For example:

• Every line must fit on an 80-column card.
• Continuation character goes in column 6.

Have these changed?

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

[Registered Coward v2]

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)