We are working with a group of developers on a project. The project is still in progress (not completed) and these developers charge us for time spent on fixing bugs on codes that were not written valid in the first place. I understand that we should pay for changes/new requests if any, but not bugs fixes for a work in progress. We also understand that once the assignment is being deployed to the live site, we may be liable for bugs fixes that may arise after a support period is being exhausted.

The question now is, is it appropriate for such charges to be levied upon us while the project is still in progress?

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

21

Time for bug fixes is generally in the intial bid for the work (It may not show up as a line item, but it is part of developement time to fix bugs found in the development process). If you think any project ever done has been created with no bugs, then you are being unrealistic and you should do the coding yourself since you are so perfect.
–
HLGEMJun 20 '12 at 16:01

1

I would guess that the downvotes are from the lack of details within your question. You may want to edit the question and provide more information. You'll get a better answer out of it too, so it's well worth the effort. Specifically, some details about what's in the contract for enforcement; what's the nature of these bugs - mainline function vs. nits; what's the stage of the project; and what's left (raw quantity wise) to be done.
–
GlenH7Jun 20 '12 at 16:01

7

@WandaPebbs, software development is complex and difficult, no one writes bug free code. Fixing bugs is part of the process and if you are think it isn't, your expectations are incorrect not the developers. Every software project ever done paid in some way for fixing bugs. You are simply being unrealistic and cheap. No decent developer would work for you twice.
–
HLGEMJun 20 '12 at 17:13

define bug, most customers define change request as a bug the dev is responsible for because they changed their mind, when actually that is a bug in the specification. There is also NAPWAR( Not A Problem Works As Requested ), is this a bug because the wrong thing was asked for? Another strike against Big Upfront Design/Waterfall approaches. The OP has their expectations way out of line either way.
–
Jarrod RobersonJun 21 '12 at 17:29

8 Answers
8

Defects are an expected result of the software development process. For a time and materials contract, I would expect that the developers charge you for the time they spend fixing bugs. This is a normal part of a developer's job. For a fixed bid contract, I would expect that the developers eat the cost of the defects and deliver the system bug free (or as close to it as the contract states) for that fixed cost. For a situation where you are employing them more directly as contractors or as employees, then it would fall under the same time and materials reasoning: it is a part of the job so they should be paid for it.

That's exactly how we used to do it. For fixed bid, we fix them for no cost, but sometimes the "bugs" were missing functionality that wasn't clear in the initial contract. A change order was used then. If it was time and materials, there was usually a lot less definition up front.
–
David HogueJun 20 '12 at 16:11

+1. It sounds like their contract is to pay developers by the hour. If they spend time working on the project, then they get paid. If the OP wants a different business model, they can try to renegotiate the contract.
–
StriplingWarriorJun 21 '12 at 18:52

To be blunt, this question implies a tremendous level of ignorance about the software development process. It might be wise to take your company web site off of your profile [especially since it doesn't exist], and go read a book on managing software development projects.

To address your specific question, as others have stated, if you want bug-free code and free bug-fixing, you have to specify acceptance tests for deliverables and negotiate fixed-bid contracts with the developers. If you hire people to put in hours on a project with no clearly-defined acceptance tests, you have incidentally agreed to pay them for their time, not their results. So yes, you should pay your developers to fix bugs. You also paid them to write the bugs. And if your project has no acceptance tests, you'll likely continue to pay them to write and fix bugs until they accidentally finish the project, or it runs out of money, or the client cancels it. None of which will reflect well on your organization.

@ Steven A. Lowe; Unfortunately, the above site is not my site nor do i have any ties with them. Ours is staffmill.com and not what you stated above. I do not have any ties to staffmills you may want to find out from them. Besides, what has my organization got to do with the question? It's just funny how some people respond to questions. One thing has nothing to do with the other. If you can help, help and if not forever hold your peace. Besides I have taken heed to some meaningful responses submitted before yours. Thanks for your contribution and hope you earn a badge or points for this.
–
Wanda PebbsJun 21 '12 at 3:48

3

@WandaPebbs: Thanks for the clarification, answer edited to remove the incorrect link. I find it curious, however, that you claim staffmill.com as your organization, yet that domain name is unregistered. As for what your organization has to do with your question, I would think that would be obvious, but perhaps it isn't. Good luck on your journey!
–
Steven A. LoweJun 21 '12 at 16:37

What are the terms of your contract? Did you specify having a user acceptance test phase? Did you make the payments contingent upon clearing UAT?

Have the modules / units / whatever been accepted by your organization? Note that there is a difference between received and accepted. Received means you have received the code and it is entering user acceptance test. Accepted means it has passed the UAT.

If the bug is found after UAT, you are generally bound to pay for the fix. If it's found during UAT then you haven't received working code yet, so the payment milestone hasn't been met.

If you didn't put any sort of acceptance provisions within the contract, then you're likely bound to be paying to fix the bugs.

I'm editorializing here - if you're in a condition where you don't have a means to enforce receiving code that works as expected, then ditch the contract now. The outside firm is only bound to deliver what is in the terms of the contract. If the contract doesn't specify what "functional" is, then you're pretty much at their mercy for what is delivered for final content.

Additional edit #1:
If you're in a "Time and Materials" contract for the development work, then there is no functional difference between paying for them to code new function or paying them to fix bugs in the new functions. Think of it this way: Just because they gave you a preview of a function doesn't mean that the function was actually delivered. So while you may have found flaws within the function preview, that just means they're not complete with developing it yet. What you see as bug fixes is really their continued refinement of the function.

Additional edit #2:
I would encourage checking to see if you formally moved from the fixed price contract to the project-log / by-the-hour (aka T&M) approach. In general, I have never advised any of my clients to accept a T&M contract when it comes to new development. There are simply too many variables in play to make a T&M contract an acceptable risk.

In a fixed price world, they are bound to fix any and all issues that prevent delivering the function specified by the contract. So bug fixes would be on their dime, not yours.

In a T&M world, there is no such thing as a bug fix. It's just additional enhancement of the code that has been generated at that point in time.

(Editorial #2) If things are bad, don't be afraid to ditch a bad contract. Pay the escape penalty and be done with it. It's very easy to get into a situation where good money is thrown after bad. Stop the bad development process; re-work the RFP and specify what is actually required; ink a new contract. It's the best way to make sure you'll get what you actually need and will save a lot of headache in working through a bad contract.

We actually started of with a fixed price model after which they advised that the project log model will be cost effective for us. As at the time we switched to the pay by the hour/project log model, there was no contract reentered into. So we assume we are still bonded by the initial. No, it hasn't been accepted by our organization nor has it been deployed to our site. I understand that once accepted, it becomes our responsibility but not when it's still in progress.
–
Wanda PebbsJun 20 '12 at 16:08

@WandaPebbs - updated based upon your comment above and on a few other answers.
–
GlenH7Jun 20 '12 at 16:18

Thank you for the tips and advise. I'll definitely follow your advise. "Ditch" is the word. I appreciate the time taken out to clear my concerns.
–
Wanda PebbsJun 20 '12 at 16:26

@WandaPebbs - To be clear, you're currently working in under "handshake agreement" for hourly pay that contradicts your signed contract that was fixed price? Because that's part of your problem, right there. They sold you hourly because it would be cheaper for you, but it doesn't sound like that's working out. I think once the hourly price hits your quoted fixed price, you need to sound some real loud alarm bells.
–
Dan RayJun 22 '12 at 13:14

Thanks Otavio. Yes we do have a contract agreement but it doesn't state client responsibility for bugs fixes when work is still in progress. No we pay them by the hour using a project log (jira.com) not salaried.
–
Wanda PebbsJun 20 '12 at 15:58

2

@Wanda If you pay by the hour, why does it matter if they're fixing bugs, refactoring, or adding new features?
–
CodesInChaosJun 20 '12 at 16:02

9

Well... if you pay them by the hour, you pay them for whatever they do during these hours. It doesn't seem to me that you have the luxury of choosing what work gets paid and what work doesn't. You have the option of firing the bad ones though...
–
Otávio DécioJun 20 '12 at 16:03

As others have answered: you should pay whatever it is your contract says you agreed to pay.

It sounds like you may now have issues with your contract and feel you are being taken for a ride. If you are unhappy with your dev team then it is your responsibility to communicate this to them in a clear and amicable way so the issue can be resolved and work can continue. It doesn't sound like you have a particular problem with the team or the work being provided but rather the billing. Have a friendly call or face-to-face meeting and ask them about it. My experience has been that this will resolve most issues quite nicely.

If that doesn't work out for you then there a bunch of greatanswers to this question already.

It might depend on the nature of the bugs. If the bugs are impeding their work on other features (for example, if Screen 1 fails to render due to an old bug, how can they add 2 new buttons to it?), then it might be cheaper to have them fix the bug and do their new work properly rather than code around the bug. In the future, you're probably better off defining this kind of situaiton more clearly in the initial contract.

I would say either the specs weren't clearly defined, or they blew their estimates (which you shouldnt have to pay for).

When seeking an estimate you need to clearly define what the functionality to be delivered is, and provide them (the dev shop) some clear definition of how the product should work and how it will be tested to verify that it works. Their job is to accurately estimate and deliver.

If the product doesn't work as expected (it doesn't pass the tests that you provided i.e. A user enters their username and password, clicks login and they are redirected to their homepage), that's not your fault.

However, if you havent defined what should happen if they enter the wrong uname / pword, and the page throws an error, that MIGHT be room to say "Well, you didnt say we had to validate the username and password" so make sure to write down what you expect each "test scenario" to result in..

clearly define what you want

clearly define how you will verify that it works the way you want

upon delivery use the agreed upon test to validate it works as intended