Code Warranty - clarification

views:

answers:

+3 Q:

Code Warranty - clarification

I am working as a consultant doing programming work for a company. I get a flat rate for components in the project (or milestones as we call them). The client recently introduced the idea of 'code warranty' to me. A term which I am unfamiliar with.

He states that 'code warranty' is the period where errors/bugs in the code will be fixed for free and it's typical for developers to give anywhere from a 90 day to 6 month warranty on their code.

Can anyone speak to this?

+3 A:

That's crap. "Errors" and "bugs" can mean anything from new features to logic changes. It is their job to ascertain the quality of the code, and verify it has been completed to their standards. If they pay you for having completed task XYZ, they should have checked out out to make sure it measures up. If they find a bug, they won't pay you till it's fixed. Coming back later and asking for it, for free, is ridiculous.

Some options you have:

Offer a support contract at a reduced rate
Make a clear distinction between a bug and a feature. Note product specs and ensure that they don't change.

Josh K 2010-08-09 17:42:23

Yeah. You can offer a support contract, you just need to scope it such that you aren't on the hook for everything. Say "I am willing to provide x hours of bug fixes for this $y." The client may not be a jerk, he may just want to know he can call you if he needs to. Try to look at this as a business opportunity.

joel3000 2010-08-09 17:50:20

It sends real fishy. Chances are they are going to do something on their side that will require your code to change, i.e. add something that needs a new feature, then they will claim that your code does not provide support for this and try and get free work out of you.
If you do end up accepting this agreement, make sure that the difference between "bug" and "feature-request" is clearly stated.

James 2010-08-09 17:45:05

Your rate just went up significantly. If the company wants an insurance against bugs instead of an acceptance test, they have to pay for it.

Also, reviewing specifications and testing just got a bigger part of your work, so each project will take a lot longer. You have to make sure that the specification specifies exactly what the product will and will not do, as you have to be able to clearly tell if something is a bug or new feature request.

Guffa 2010-08-09 17:49:05

I'll play devils advocate and ask: why does having to deliver software that actually works significantly raise your rate? You just admitted that your code is not fully tested and/or does not implement all of the specifications on a normal occasion. Why is that? Is that an issue with the coder or the person who is trying to get a product that works?

Mike M. 2010-08-09 18:09:26

@MikeL It's an issue of what actual "bugs" are and what the company is calling "bugs" to get you to do work for free.

Josh K 2010-08-09 18:13:02

@Mike M.: It depends on what's "normal". If you usually have imprecise specifications and short testing periods, bugs and specification flaws will appear. If you want to raise the demands on the code, the demands on the specification and testing automatically have to be raised also.

Guffa 2010-08-09 18:27:08

dunno if you noticed this to the right http://stackoverflow.com/questions/939985/what-is-a-standard-warranty-period-for-software-development

2010-08-09 18:25:14

ansaurus

tags:

views:

answers:

Code Warranty - clarification

related questions