Should I pay my developers for bugs fixes for a project or work that's still in progress?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

(I am not a lawyer)

It depends - what do you have written in a contract with them? If they are salaried employees you are responsible for paying them no matter what.

Answer 5

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 great answers to this question already.

Answer 6

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.

Answer 7

There is no way you can assume the programmers to write perfect code:

1. Fixing bugs in normal software project takes at least 1/3 of all the time used. In maintainance phase, more than 1/3.
2. Even after spending large amounts of time and money fixing bugs, nasa still lost space shuttles because of software problems. I think you will run out of money long before you get to the same quality.
3. Outsourcing the responsibility to fix bugs to outside vendors is definitely a good way to make your project fail.

Answer 8

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

1. clearly define what you want
2. clearly define how you will verify that it works the way you want
3. upon delivery use the agreed upon test to validate it works as intended

not providing enough information up front will end up costing you..