5

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?

Wanda Pebbs
  • 103
  • 1
  • 3
  • I think it depends on where in the process the bugs are discovered. Development? Testing? Acceptance? Post acceptance? – Rig Jun 20 '12 at 15:56
  • 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. – HLGEM Jun 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. –  Jun 20 '12 at 16:01
  • Did you sign off on the initial work? and then found bugs later on which then needed to be fixed? or was the work never "completed" – hanzolo Jun 20 '12 at 16:09
  • @HLGEM I guess you are one of such developers. Btw - noone is perfect. How about writing a valid code in the first place. Should the life-cycle of the project be dependent upon bugs fixes? We would gladly pay extra if assignment has been completed, tested and deployed to the live site. Once deployed, whatever happens then is/should be our responsibility IMOHO. – Wanda Pebbs Jun 20 '12 at 16:18
  • @hanzolo It was never completed. They are still working on it as we speak. – Wanda Pebbs Jun 20 '12 at 16:20
  • @Rig The project is still in the development process. – Wanda Pebbs Jun 20 '12 at 16:49
  • 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. – HLGEM Jun 20 '12 at 17:13
  • 1
    What does your contract say. Do you have a contract guaranteeing bug free code or that you will not have to pay for them to fix them? Often times bugs are created by changing requirements. You could always get a fixed price bid. Those tend to cost more but you have a fixed cost for the project. But this question is not about programming its about business. – SoylentGray Jun 20 '12 at 20:56
  • This is what a contract is for. –  Jun 21 '12 at 02:50
  • 2
    The downside of paying contractors for every bug that they fix is that they will often start finding a lot more bugs... http://dilbert.com/strips/comic/1995-11-13/ – briddums Jun 21 '12 at 14:23
  • This is not as bad a question as the attacks against Wanda seem to imply; in particular, there's not enough information for us to know whether the bugs in question are due to lack of detail in the design or just incorrect code. – Mike Partridge Jun 21 '12 at 17:02
  • @WandaPebbs: this is a very good blog post related to your problem: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html – Mike Partridge Jun 21 '12 at 17:10
  • 2
    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. –  Jun 21 '12 at 17:29
  • L9lll9lllllllllll8lllllllli8 – meda Aug 26 '16 at 15:19

8 Answers8

28

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.

RationalGeek
  • 10,077
  • 7
  • 38
  • 56
  • 5
    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 Hogue Jun 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. – StriplingWarrior Jun 21 '12 at 18:52
16

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.

yannis
  • 39,547
  • 40
  • 183
  • 216
Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
  • 1
    @ 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 Pebbs Jun 21 '12 at 03: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. Lowe Jun 21 '12 at 16:37
  • 2
    @StevenA.Lowe - +1 for "until they accidentally finish the project" – hanzolo Jun 21 '12 at 18:58
5

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 Pebbs Jun 20 '12 at 16:08
  • @WandaPebbs - updated based upon your comment above and on a few other answers. –  Jun 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 Pebbs Jun 20 '12 at 16:26
  • hourly workers will always work hourly – hanzolo Jun 20 '12 at 16:31
  • @WandaPebbs - Severing a contract can be (is) painful, so I don't advise it lightly. But if the writing is on the wall that there are many months or years of headache ahead, then it starts becoming a valid option. –  Jun 20 '12 at 16:58
  • 1
    @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 Ray Jun 22 '12 at 13:14
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.

Otávio Décio
  • 5,299
  • 23
  • 34
  • 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 Pebbs Jun 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? – CodesInChaos Jun 20 '12 at 16:02
  • 10
    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écio Jun 20 '12 at 16:03
  • @CodeInChaos it matters because the cost of fixing the bugs as it appears from the invoicing is much more than the cost of building a feature. Generally, the work is being stagnant (no improvements) yet we get invoices for bug fixes greater than what we paid/pay for actual features. – Wanda Pebbs Jun 20 '12 at 16:12
  • 3
    If you want to see "features" and "improvements" prioritized over bug fixes then you should communicate that to the contractors. – user16764 Jun 20 '12 at 20:27
  • @WandaPebbs It seems to me you may be arguing about terminology. They may say they build a feature for 5 hours and then fix bugs for that feature for 10 hours. I might say I spend 14 hours building a feature then 1 hour fixing bugs for it because I don't call it built until I have don't a lot of testing. They may call it built when it is ready to start testing. Either way, it takes 15 hours to get a good working feature out of it. – Justin Jun 21 '12 at 18:49
4

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.

Community
  • 1
NoobsArePeople2
  • 351
  • 1
  • 3
2

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.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
2

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.
tp1
  • 1,902
  • 11
  • 10
  • 5
    NASA did not lose Space Shuttles due to software problems. For Challenger: O-ring was hardware. For Columbia: Wing damage was hardware. –  Jun 21 '12 at 02:52
  • 1
    @tp1: -1, see Thorbjørn's comment. – jmoreno Jun 21 '12 at 03:34
  • @jmoreno: Guess it's possible to do it without catastrophic failure, but they're still going to run out of money. – tp1 Jun 21 '12 at 05:42
  • 2
    @tp1: and if that's all you'd said, it would be +1 instead. But as it is your answer includes a major, incorrect, statement. – jmoreno Jun 21 '12 at 05:59
  • #2 is blatantly incorrect factually. NASA never lost a shuttle because of any software failures. –  Jun 21 '12 at 17:49
  • Well, few shuttles exploding seems to be a SUCCESS for the software project, so guess everything is ok. – tp1 Jun 21 '12 at 23:11
1

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

hanzolo
  • 3,111
  • 19
  • 21