Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How Long Should Devs Support Software Written For Clients?

Soulskill posted more than 2 years ago | from the just-until-the-next-venus-transit dept.

Software 384

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

Sorry! There are no comments related to the filter you selected.

Too late to be asking.... (5, Insightful)

jmorris42 (1458) | more than 2 years ago | (#40237829)

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.... (5, Informative)

Anonymous Coward | more than 2 years ago | (#40237955)

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.... (0)

Anonymous Coward | more than 2 years ago | (#40238047)

Agreed - this should have all been in the original contract, especially since it sounds like you're doing contract to meet a design specified by them as opposed to simply being a software vendor selling a product.

Other than that, I don't know that there is really an "industry standard" that can be applied to all software companies - I guess the OP would really be looking for the standard for the "website for hire" industry

For comparison, I work for a fairly large software/database company with a couple hundred customers and our software contracts are for millions of dollars. All version upgrades and fixes are included as part of their standard costs, with a new version released ~ every 15 months. Some fixes and enhancements may be retrofit to some prior versions, depending on scope, how safe we think those code changes would be, and need (i.e. fix is critical or needed for regulatory compliance). Any new development that has to be done to meet special needs for a particular customer (such as to interface with a third party system only they have) is billed by the hour.

Re:Too late to be asking.... (0)

Anonymous Coward | more than 2 years ago | (#40238279)

Re:Too late to be asking.... (2)

cpu6502 (1960974) | more than 2 years ago | (#40238297)

Microsoft has supported XP for seemingly forever. At no charge (3 major updates and also minor bugfixes - all free). But you're right this Questioner should have a contract somewhere to specify exactly how long the software will be supported. One could argue that "no time specified" means the customer should get no support at all. They should not have signed the contract, if they did not like those terms.

Re:Too late to be asking.... (2)

Jane Q. Public (1010737) | more than 2 years ago | (#40238479)

That's not the same thing at all. Stuff is specifically written to be compatible with Windows, not the other way around.

His situation is reversed. He puts a web app out there, and browsers / technology / other software will constantly be changing around it.

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

icebike (68054) | more than 2 years ago | (#40238447)

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.

Programming is like having sex without a condom... (5, Funny)

Anonymous Coward | more than 2 years ago | (#40237851)

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

Your bugs.. your problem (-1, Troll)

jhoegl (638955) | more than 2 years ago | (#40237865)

They didnt code it, you did.
Why should they pay to fix your mistakes? Why do you think people have/had problems with MS? Because they charge you to fix them. Windows Vista and Windows 7 is a great recent example.

Re:Your bugs.. your problem (1)

John Courtland (585609) | more than 2 years ago | (#40237915)

You're kidding right?

Re:Your bugs.. your problem (3, Insightful)

radiumsoup (741987) | more than 2 years ago | (#40237917)

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.

Re:Your bugs.. your problem (5, Insightful)

Anonymous Coward | more than 2 years ago | (#40237923)

>>They didnt code it, you did.

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

Re:Your bugs.. your problem (4, Funny)

MrEricSir (398214) | more than 2 years ago | (#40237971)

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 (3, Interesting)

radiumsoup (741987) | more than 2 years ago | (#40238035)

I charge people to run Windows Update for them, so I'm getting a kick, etc. ;)

Re:Your bugs.. your problem (0, Interesting)

Anonymous Coward | more than 2 years ago | (#40238155)

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:Your bugs.. your problem (5, Funny)

radiumsoup (741987) | more than 2 years ago | (#40238265)

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

Windows Updates is free. Just like Windows (0)

Anonymous Coward | more than 2 years ago | (#40238301)

In fact, I believe more than half of world population doesn't anything for all the software they use, no matter where it comes from. If you are among these software giants that can afford to have so many non-paying clients, and write it off as "marketing costs", good for you. But most of us aren't quite there, and we charge by the hour.

Re:Your bugs.. your problem (5, Insightful)

jdastrup (1075795) | more than 2 years ago | (#40237983)

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 (0)

Anonymous Coward | more than 2 years ago | (#40238321)

Because they didn't pay enough to have it written correctly the first time.

Re:Your bugs.. your problem (1)

Midnight Thunder (17205) | more than 2 years ago | (#40238403)

Indeed, though a service level agreement is always worth having. That way everyone knows ahead of time where they stand and whether to end the relationship early if the terms are unacceptable to either party.

Always get the user to end user testing and to sign off on it. If they refuse to do so, then you should indicate that you aren't liable for bugs that could have been caught. Anything caught outside of the testing period is subject to the SLA.

As to source, big companies sometimes insist on either having the source or keeping it in escrow, in case you disappear, but having infinite life-time support for free is excessive. Is there anything in life that comes with type of deal?

Note, if a contractor fixes my roof then I have a guarantee against defects for 5 years. If it runs into problems that are due to their workmanship, then they have to take care of it.

Ok no problem (1)

Sycraft-fu (314770) | more than 2 years ago | (#40237995)

Tell me what it is you do for a living? Because whatever it is, any problem that occurs with your work, ever, for the rest of time, I am going to expect you to fix without being paid.

Don't like that? Then perhaps reconsider your attitude towards this.

Re:Ok no problem (1)

Ichijo (607641) | more than 2 years ago | (#40238141)

Your analogy doesn't work because software doesn't wear out like most things do.

Re:Ok no problem (4, Insightful)

Tridus (79566) | more than 2 years ago | (#40238197)

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:Ok no problem (1)

Ichijo (607641) | more than 2 years ago | (#40238351)

If your software doesn't work on a new version of Windows, it's either because (1) there was always a bug in your software which didn't manifest itself in the old version of Windows, or (2) something changed in the OS that requires changes in the software to work (for example, for security reasons), or (3) a bug in Windows.

The first case is a bug that always existed in your software, so it doesn't fall under "ongoing maintenance." The second case is a new requirement ("make it work under the new version of Windows"), and new features don't qualify as "ongoing maintenance." The third case is also outside of your control.

Re:Ok no problem (1)

malkavian (9512) | more than 2 years ago | (#40238239)

Of course it does. It's programmed to fit on a particular machine with a particular OS/tools. These wear out. The media the software sits on degrades, and can occasionally corrupt.
The APIs eventually change. All sorts of things happen, which is the software analog of 'wearing out'.
I'd treat support as a standard warranty deal if nothing was agreed (i.e. it depends on what you paid for it; If I charged you £50k for a wordprocessor, I'd expect to be supporting it for some time; if I charged you £2k for a reasonably complex bit of software, you'd be lucky to get 1 year out of it). It all depends on what could reasonably be considered the 'lifetime' of a product.
But, after that, any support, and they pay.

Re:Ok no problem (1)

Ichijo (607641) | more than 2 years ago | (#40238399)

It's programmed to fit on a particular machine with a particular OS/tools. These wear out.

But not the software.

The media the software sits on degrades, and can occasionally corrupt.

But not the software.

The APIs eventually change.

If your customer wants you to make your software work with new APIs, then that's a new feature which they can be expected to pay for. It's not a bug in your software.

Re:Ok no problem (1)

alexborges (313924) | more than 2 years ago | (#40238339)

You have never, ever written any kind of software, have you?

Re:Your bugs.. your problem (0)

Anonymous Coward | more than 2 years ago | (#40237999)

Uh-huh.

But they also ground you on price in the first place so much so that there was not enough room in the budget for proper testing / debugging. And don't forget that they changed the specs three times during development.

If a client wants software to be "BugFree" there's plenty of companies offering that level of service - IBM, WindRiver, etc.

Good, Quick, Cheap - Pick Two.

Re:Your bugs.. your problem (1)

Midnight Thunder (17205) | more than 2 years ago | (#40238425)

Uh-huh.

But they also ground you on price in the first place so much so that there was not enough room in the budget for proper testing / debugging. And don't forget that they changed the specs three times during development.

If a client wants software to be "BugFree" there's plenty of companies offering that level of service - IBM, WindRiver, etc.

Good, Quick, Cheap - Pick Two.

Even then there is no bug free software. What it is free from are bugs that testing would have discovered. Anything after is subject to the SLA (service level agreement)

Re:Your bugs.. your problem (4, Insightful)

sideslash (1865434) | more than 2 years ago | (#40238009)

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.

Re:Your bugs.. your problem (3, Interesting)

Anrego (830717) | more than 2 years ago | (#40238013)

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 (1)

DarwinSurvivor (1752106) | more than 2 years ago | (#40238037)

If they want perfect, bug free code, then their developement time better be in the hundreds of years. If they want bugs to be fixed that you didn't have time to fix during developement, then they better be ready to PAY you to keep working on it.

Re:Your bugs.. your problem (0)

CanHasDIY (1672858) | more than 2 years ago | (#40238373)

If they want bugs to be fixed that you didn't have time to fix during developement, then they better be ready to PAY you to keep working on it.

Read:

"You want us to program some software for you? No problem. Oh, you wanted software that actually works? That costs extra."

Seriously, if you're knowingly writing bad code just so you can charge people to fix what you should have done right in the first place, you won't stay in business long.

Re:Your bugs.. your problem (3, Insightful)

thatseattleguy (897282) | more than 2 years ago | (#40238055)

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.

Re:Your bugs.. your problem (1)

Ichijo (607641) | more than 2 years ago | (#40238185)

A software bug is not "a mistake". It's an inevitable part of the process...

Why can't it be both?

Re:Your bugs.. your problem (1)

thatseattleguy (897282) | more than 2 years ago | (#40238259)

For certain definitions of the the term, sure, it's both; for others, not.

"Mistake" was put in quotes in what I wrote because of the original poster's implication was that all bugs were things completely avoidable, serious failures that were something the programmer should rectify for free and that not doing for a customer so was immoral/improper - like mis-assembled car that should have its manufacturing defect(s) covered under warranty. Custom-written software isn't in the same category, IMHO. If you want perfection, you have to pay for testing to perfection - not something most clients are willing (understandably) to do.

Re:Your bugs.. your problem (1)

alexborges (313924) | more than 2 years ago | (#40238353)

It can. Usually isnt.

The only software that has absolutely no bugs from the rollout is code more than 20 years old that hasnt been touched in the last 10 and does exactly what it did back then.... and even then, sometimes the unexpected can come up way in the future.

You have no idea of how software is made, do you?

Re:Your bugs.. your problem (0)

Anonymous Coward | more than 2 years ago | (#40238075)

They give you an unrealistic dead line.
bugs are to be expected.

Define "bug" (1)

JSBiff (87824) | more than 2 years ago | (#40238147)

So, what if the customer upgrades some piece of software in the environment that is a dependency of your software - a jvm, or .net runtime, or a library, or a database engine, or the operating system or webserver. Something breaks. It breaks not because of any mistake you made, but because something in the dependency changed. Maybe a bug was introduced into the dependency, or a deprecated function or feature was removed.

Should you be expected to update the code to deal with the new version of the dependency, for free? A lot of "bugs" that show up after 2 or 3 months fall into this category.

What if the "bug" exists because of a demand made by the client during development, and you even tried to warn them that this was a mistake and would lead to problems, but they insisted, so you gave them what they demanded, not what they really needed. Then, a year later, they finally come to their senses and want it "fixed" - should you be expected to do that work for free?

Re:Define "bug" (3, Interesting)

ganjadude (952775) | more than 2 years ago | (#40238345)

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

Forever is a long time... (1)

Anonymous Coward | more than 2 years ago | (#40237867)

Are they providing infinite amounts of cash in return for your infinite amounts of labor?

Re:Forever is a long time... (1)

xpax666 (2625167) | more than 2 years ago | (#40238099)

Exactly. While I understand the analogies to things like the brakes on your car, it doesn't really stand up to much scrutiny. The car manufacturer gives you a warranty, and even brakes aren't covered under that unless it's a manufacturing defect. After the warranty is over, unless there was a recall notice, it's up to you. In the case of software, the simple fact of the matter is that NO software is bug-free. Even if it somehow magically were bug-free when delivered, changes to OS, configuration, etc can cause new bugs to be created simply by introducing situations that could not have been anticipated during the initial development. In the end, it would be financial suicide to fix bugs forever for free. A short period (a couple of months) after delivery should be good enough, or in a case where user acceptance testing is required, I'd go with no time at all. If they have these sort of onerous requirements, then it's up to them to figure it out during that process.

Depends on your business model... (0)

Anonymous Coward | more than 2 years ago | (#40237877)

..and if you want to make a profit. Supporting a life cycle of software that has no terminating date can get you into some trouble because you are spending man hours at a cost supporting it.

Never. (5, Insightful)

LWATCDR (28044) | more than 2 years ago | (#40237883)

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

Re:Never. (1)

Anonymous Coward | more than 2 years ago | (#40237977)

IANAL.

Have a clear deliverable. Deliver it. After that, it is up to you.
Making clear and explicit what encompasses the deliverable is a not insignificant amount of work, but it is almost always a good idea.

After you've delivered you can work for goodwill if you believe that the goodwill will compensate you for the opportunity cost of spending your time on this.
This really *can* work, but won't always work.

If this is not encoded in your contract, time for a new contract for the new scope of work.

As far as I can tell, the current industry convention is to charge more than the work should cost, to offer shit for support, and possibly to take the money and run.
It sounds like you're doing better than that.

3 Months (5, Informative)

Anonymous Coward | more than 2 years ago | (#40237887)

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 (5, Interesting)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#40238285)

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

your client (0)

Anonymous Coward | more than 2 years ago | (#40237889)

has an ID-10-T problem

Re:your client (0)

Anonymous Coward | more than 2 years ago | (#40237913)

PICNIC problem.

Problem in chair, not in computer.

Re:your client (2)

DarwinSurvivor (1752106) | more than 2 years ago | (#40238057)

I prefer PEBKAC.
Problem Exists Between Keyboard and Chair.

Re:your client (1)

radiumsoup (741987) | more than 2 years ago | (#40238077)

my favorite was always "ES(T)O"... where the Equipment is Smarter (T)han the Operator

Re:your client (0)

Anonymous Coward | more than 2 years ago | (#40238199)

PEBKAC problem

Problem Exists Between Keyboard And Chair.

duuuuuuuuuurr (-1)

Anonymous Coward | more than 2 years ago | (#40237893)

If Honda sells you a car with defective brakes, do they have the right to charge you to fix them?

Quit being a twat.

Re:duuuuuuuuuurr (-1)

Anonymous Coward | more than 2 years ago | (#40237997)

When the brake pads wear out, do they have the right to charge you to replace them?

Re:duuuuuuuuuurr (0)

Anonymous Coward | more than 2 years ago | (#40238041)

"supported with bug fixes "

Bugs = defects

Bugs != regular matinence.

Re:duuuuuuuuuurr (1)

Nadaka (224565) | more than 2 years ago | (#40238191)

>90% of "bugs" are features, conditions and behaviors not covered by the systems design.

honda doesn't sell me a custom car (1)

Chirs (87576) | more than 2 years ago | (#40238409)

So they can test to reasonable levels of assurance.

For custom software work, that level of testing is generally too expensive to give unlimited guarantees.

The client is always right (4, Insightful)

Wonko the Sane (25252) | more than 2 years ago | (#40237905)

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:The client is always right (1)

Anonymous Coward | more than 2 years ago | (#40237967)

So estimate the lifetime of the company, and the number of working hours that the company might operate, and assume that the remaining life of the company will be dedicated to supporting that product (?). That one time fee oughtta get them to reconsider :).

Re:The client is always right (2)

Sunshinerat (1114191) | more than 2 years ago | (#40238393)

I would provide x amount of time for warranty (say two months) and provide the option to buy into service (monthly fee) that covers feature and security fixes.
The best part of a service model is that you keep contact with the customer and you can up-sell them to the next feature release.
This model does not work as well for all custom work.

For custom x months of warranty plus $x per hour for changes and fixes. Providing them with a lifetime support option is very unpredictable and may scare the customer away. They may plan on using the solution for 3 years where you are covering your ass when you need to fix it 20 years from now (current year equivalent: you need to keep that prehistoric server running to make minor changes in COBOL...) and account for that somehow. Be specific what lifetime warranty is when you go that route, sometimes it is just educating the client on expectations.

Your bugs, still their problem (2)

ElectricSpit (1821746) | more than 2 years ago | (#40237909)

I still think that even if it was your fault the bug exists, they should still pay you to fix it. I mean, every bug can't be your fault it is impossible to test every possible case and it's just part of the life cycle of software. Don't stop providing support as long as they pay!

Get it in writting (2)

greywire (78262) | more than 2 years ago | (#40237933)

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!

Re:Get it in writting (0)

Anonymous Coward | more than 2 years ago | (#40238067)

...love to change things as you go

Like Oracle [slashdot.org] ?

The key word here is "Support Contract" (3, Insightful)

I kan Spl (614759) | more than 2 years ago | (#40237941)

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.

Depends on the industry (2)

Stargoat (658863) | more than 2 years ago | (#40237951)

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.

Refer to your original contract (1, Informative)

DragonWriter (970822) | more than 2 years ago | (#40237957)

How Long Should Devs Support Software Written For Clients?

As long as the clients have paid for, as specified in the terms of the development contract (except insofar as the developer has an interest -- e.g., in developing goodwill -- that outweighs the cost of the support, or applicable law -- e.g., general provisions governing warranty obligations that the contract did not modify, either because the language didn't address them or because the law doesn't allow contracts to modify them -- imposes additional obligations.)

Just bug fixes? (1)

Anonymous Coward | more than 2 years ago | (#40237963)

If that's all they want is for your company's work to be guaranteed, then why not?

Software has gotten an easy ride in regards to quality and vendors backing up their work. Might as well stand out from the crowd. I mean if another type of product had software's reputation, I would never buy it. Also, that company would be out of business.

Speaking of which, this something that's really hindering the medical software business. Folks are so used to software being buggy that their reluctant to adopt anything that can affect patient health.

Be careful... (5, Insightful)

billster0808 (739783) | more than 2 years ago | (#40237969)

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!

Cry about it (0)

Anonymous Coward | more than 2 years ago | (#40237975)

What are they going to do, cry about how unfair it is that you won't work for free?

People who want to abuse you always feel entitled to abuse you. It's their deity-given right, and how dare you question their rights.

Unless they have a written contract or something else legally compelling you to do it, they have nothing.

All that having been said, I find there is value in learning from my own mistakes, which is why I often look into claims of bugs or problems with the work that I have done. I generally put the foot down after 90 days though. I want to do good quality work, and if there is something quick and easy that I can do to improve past work, I'll do it. I get the benefit of realizing my mistake and not doing it again. However, I don't work for free and I try to set reasonable expectations with the client BEFORE taking on work to try and prevent disagreements before they occur. That's what contracts are for.

Repellent (1)

Anonymous Coward | more than 2 years ago | (#40237985)

Send them a can of mosquito repellent and be done with them.

Hmmm... (2)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#40237991)

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.

Support as long as you are paid for it (1)

gweihir (88907) | more than 2 years ago | (#40238015)

Of course, clients can pay up-front for, say, 10 years of support. But they only get what they pay for, no matter the details.

After accpetance, it's pay-as-you-go (5, Insightful)

dbc (135354) | more than 2 years ago | (#40238045)

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 (0)

thebeige (2555996) | more than 2 years ago | (#40238069)

Fuck I hate third party developers. I wish they would all stop blaming me!

Really, It Depends (1)

rueger (210566) | more than 2 years ago | (#40238059)

I'd say if you've made some obviously boneheaded mistake, something that you should have seen and fixed, then yeah, bite the bullet and fix it for them.

On the other hand, if it's the kind of day to day stuff that comes under the heading of "maintenance" then charge them.

Car analogy: Recall and repair of a manufacturing defect (Manufacturer pays) vs an oil change and brake relining (You pay).

Kernel Panic: Penguins on the bus... (1)

ae1294 (1547521) | more than 2 years ago | (#40238081)

The EU tends to think 2 years for bugs... I think you should have really thought about this before writing the first line of code but hey it's not like this could end in a lawsuit or a reputation problem or anything...

If they've got the source, they don't need you. (1)

Medievalist (16032) | more than 2 years ago | (#40238085)

Give them a copy of the source code, and if they don't like what you charge for support, they can hire somebody else to do it.

Of course if they come back later and want you to fix whatever their el cheapo programmer did to your code, they're going to have to pay extra. ;)

NDA Required Here (1)

theshowmecanuck (703852) | more than 2 years ago | (#40238397)

If the OP actually owns the code and he/she gives the client a copy of the source code, then they also need to have the client sign a Non Disclosure Agreement or the OP could end up in a worse situation. It should state the client can't disclose or sell the code and use it only for internal purposes, etc. etc. etc. Imagine a system where all the code you spent time and money to develop is given away and anyone who wants it can use it. You'd be out of business. And you wouldn't be able to pay off the bills you incurred while not making money while writing the initial code. But very, very often the code ends up being owned by the people who commissioned it to be written. This would then invalidate your point entirely.

Service Contract (1)

mauriceh (3721) | more than 2 years ago | (#40238093)

Offer them a service contract.

Staff vs. Contract (1)

Shamanin (561998) | more than 2 years ago | (#40238095)

If you want support for any product you have to pay for it; either by contract agreement (low risk to business), pay as you go (low risk to contractor), or having someone on staff to maintain it.

Short answer: until the contract expires. (1)

Nadaka (224565) | more than 2 years ago | (#40238101)

Long answer: as long as they are willing to pay you at a competitive rate.

Maintenance contract (0)

Anonymous Coward | more than 2 years ago | (#40238111)

For websites, we offer a maintenance contract that covers a few hours each month, to be used for bug fixes or upgrades. Unused hours also "roll over" into the next months, and we use those for small feature upgrades.

Project Management 101 (0)

Anonymous Coward | more than 2 years ago | (#40238119)

Should have all been in the project charter.

You sound reasonable (1)

medv4380 (1604309) | more than 2 years ago | (#40238123)

No one in their right mind should support "forever", and any client who is foolish enough to demand it can go elsewhere. Anyone who says "yes" to those terms will be bankrupt by the idiot clients who demand that service. The fools who want that service will find that they have software that the vendor no longer exists to torment.

What Type of Software is important (0)

Anonymous Coward | more than 2 years ago | (#40238131)

You should sell support contracts along with your software

Two months is too short (0)

Anonymous Coward | more than 2 years ago | (#40238139)

Having been a developer for over 30 years. Unless the application is downright trivial in nature, I believe that two months is much too short a time frame to provide bug fixes. It should be at least 6 months. Now to be clear: these are bugs (i.e. things that you didn't do correctly), not enhancements or improvements to the application. Some complex applications don't exhibit their underlying problems (bugs) until much later or when they are under significant load (which can take a while)

As others have pointed out, you REALLY should have agreed on this up front and even provided a support contract that makes you money while providing the customer with support for the application for several years at least. You can't work for free, but you can't overtly charge for your mistakes either. A service contract protects both entities in the relationship.

Simplest formula EVER. (0)

Anonymous Coward | more than 2 years ago | (#40238161)

Ditch idiot customers by charging them exorbitant rates REGARDLESS of the demands.
You will never be able to educate the idiot to your benefit.
And idiot does not mean ignorant - it's a fine line but idiots don't learn or listen.
I stay very busy with good customers who respect me, listen to my advice and purchase my products.

6 months, out of courtesy (1)

Bizzeh (851225) | more than 2 years ago | (#40238179)

6 months, out of courtesy. but really, your not required to give any sort of ongoing support unless its in some sort of written contract in place stating how much you will do for free, and for how long, and how much everything else will cost the client. its usually best to aim for a £100/hr for software dev and set your self a minimum amount that you would be willing to work for.

You can always... (0)

Anonymous Coward | more than 2 years ago | (#40238187)

...release your clients' velociraptors if they make you fix their bugs for free.

Industry convention (1)

countach (534280) | more than 2 years ago | (#40238227)

Industry convention, by which I mean what companies like IBM and their ilk do to customers, is they deliver crap to their customers then charge them an arm and a leg to fix it. I don't know that industry convention is particularly helpful when you're a small time guy trying to earn a living.

Like others have said, you should agree to a sign off period, but if you want to make your customers happy, you might consider fixing the worst most serious cases of bugs for free for a lot longer. But you would restrict it to really blatant bugs.

It's called a Service Contract. (0)

Anonymous Coward | more than 2 years ago | (#40238251)

If maintenance and updates aren't clearly spelled out in the original contract, if the client wants work done outside the scope of that contract, then it's time for a new contract that specifies service provider responsibilities and client remuneration in exacting detail.

On the one hand there's "if it's worth doing it's worth doing right," and on the other hand it's work for hire. If you're not getting paid - if you haven't already been paid - for the work in question, then negotiate. Don't do it gratis.

Bugs must be fixed (1)

Parker Lewis (999165) | more than 2 years ago | (#40238269)

Well, if you have a proper Quality Assurance in parallel with your coding (but real QA, not only monkeys checking UI), the amount of bugs will be minimized. So, in the contract, I always specify: clear bugs will be fixed. Any issue that is more to feature request, will be cost estimated.

Depends... (1)

Nethemas the Great (909900) | more than 2 years ago | (#40238275)

There's no easy answer to what is "typical" because so many variables exist, especially with custom software. A common model for non-custom work is an annual maintenance/assurance contract. Client's buy the software, and get one year maintenance. After that they pay {x} amount each year to renew that contract. During the life of the contract the client is eligible for support and product updates.

mandatory car analogy (1)

LinuxRulz (678500) | more than 2 years ago | (#40238287)

supporting software indefinitely is like buying a car and asking for infinite replacement of parts forever.

But I do agree on a small "warranty" period, which may range from a few months to a year, just so that most bugs gets corrected but after that it's "mechanic billed by the hour".

Latent Defects (3)

GumphMaster (772693) | more than 2 years ago | (#40238317)

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

A useful car analogy (1)

gstrickler (920733) | more than 2 years ago | (#40238333)

Some people have tried car analogies that don't work. Here's one that does.

Car manufacturers cover certain SAFETY related defects indefinitely because the govt requires it (or maybe because they believe it's cheaper to fix than be sued). However, they generally only cover manufacturing defects for the duration of the warranty. They don't "fix" the car when environments and specifications change. e.g. Cars designed for leaded fuel weren't retrofitted to use unleaded fuel (although high octane unleaded fuel would usually work), and the manufacturer isn't going to update your car because a tire manufacturer stops making tires in the specified size. These things are the responsibility of the buyer.

Same concept applies to most other products, why should software be any different?

It shouldn't. First, have a contract the specifies the requirements, and specifies a length of time during which you'll offer free support for bug fixes or failure to meet the specifications (even if they signed off on it since sometimes it's not practical to test all specifications on delivery). Changes to specifications, including compatibility with other software/systems, and bug fixes after that term are chargeable items. For chargeable items, the developer (company, not necessarily the individual programmer) may at his discretion choose not to charge, but it's entirely up to the developer. For trivial fixes, it's often more trouble to create and handle an invoice so you might choose not to charge, and that fosters good customer relations. For larger issues, you have to consider more factors, just like a vendor of any other type of product.

Why do you have bugs? (1)

under_score (65824) | more than 2 years ago | (#40238439)

Seriously. If you aren't using ATDD (Acceptance Test Driven Development) and TDD (Test Driven Development), then you have no excuses. Support them forever. I consider it unprofessional to release software with any known bugs and I have been doing this successfully for 10+ years. ATDD proves to the client that you have built what they want and that it functions as they expect (this is your contract) and TDD proves to you yourself that the internal quality of the code will hold up as well (very low rates of unexpected problems). Defects are preventable.

Think of this like surgery: if you are being rushed into the OR, you don't yell at the surgeons and nurses to NOT wash their hands and just dig into you. And even if you did, they would ignore you. ATDD and TDD are a lot like washing your hands before surgery. If you don't do it, don't be surprised at the consequences... it can be fatal.

Pull an Adobe (1)

CanHasDIY (1672858) | more than 2 years ago | (#40238441)

Make some minor/major tweaks, repackage it as Version 2.0 or whatever, and tell them that the old version is no longer supported. Then you can negotiate a service contract for the "new" software.


Hey, it works for the big dogs...

If the contract doesn't specify.... (0)

Anonymous Coward | more than 2 years ago | (#40238453)

Then there is no obligation to do so. Anything after initial testing is either out of the goodness of your heart or a change request outside the scope of the original contract. If you didn't specify an initial testing period during which defects would be fixed at no additional cost in the contract (or verbal negotiations which are nearly as good, for your purposes) then my understanding is the default would be your state's default under fitness for purpose, or similar. These tend to not be favorable to the buyer.

support contract or fire the client (1)

xpatch (1188047) | more than 2 years ago | (#40238491)

Get a lawyer to do a support contract. Secondly fire the client they will never be happy.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?