Is this fair on a contract?
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
Is a "Hello World!" app? Because if it has any more significance or business-criticality than that, you might want to add another ten minutes or so. (Heavy on the "so".)
I wanna be a eunuchs developer! Pass me a bread knife!
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
I must be missing something here; you'd prefer that he not test and fix bugs...? If he's got a contract based on a flat bid then I might understand, but if he's submitting billable hours because that's how the contract is structured then I'm not sure what the gripe would be.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
I'm sure he'll put the bugs back if you ask him nicely.
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
-
I'm sure he'll put the bugs back if you ask him nicely.
-
I must be missing something here; you'd prefer that he not test and fix bugs...? If he's got a contract based on a flat bid then I might understand, but if he's submitting billable hours because that's how the contract is structured then I'm not sure what the gripe would be.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
He's mentioned on the "estimate" . 1.Development of module A - $x 2.Development of module B - $y Etc And we arrived at a $Z as an "estimate". The way he's billing on "testing & bug fixes" feels like it's gonna crash out this estimate. I think we should have spent more time on drafting the contract.
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
Um...I'd tell them to #sand. You're paying for a working product. On the other hand, "bug fixes" are are part of the dev process if it hasn't been released yet. They shouldn't have broken it out like that.
We won't sit down. We won't shut up. We won't go quietly away. YouTube, VidMe and My Mu[sic], Films and Windows Programs, etc. and FB
-
Um...I'd tell them to #sand. You're paying for a working product. On the other hand, "bug fixes" are are part of the dev process if it hasn't been released yet. They shouldn't have broken it out like that.
We won't sit down. We won't shut up. We won't go quietly away. YouTube, VidMe and My Mu[sic], Films and Windows Programs, etc. and FB
GenJerDan wrote:
"bug fixes" are are part of the dev process if it hasn't been released yet
correct.:thumbsup: I guess the "estimate" model wouldn't work. They can arbitrarily stretch it to their favor. What if he adds 32 hours on a bug fix tomorrow? saying it's a tricky, critical bug? We dont want to get into how he introduced a bug & fixing it. It should be internal to him. A fixed cost deal would've been a trouble-free one.
-
He's mentioned on the "estimate" . 1.Development of module A - $x 2.Development of module B - $y Etc And we arrived at a $Z as an "estimate". The way he's billing on "testing & bug fixes" feels like it's gonna crash out this estimate. I think we should have spent more time on drafting the contract.
Well, it sounds like you didn't get a flat rate bid from him. Your option is this: if he blows past his estimate you might want to start to question the billable hours and he might work with you on that, but the fact is that it looks like he's being straight with you about what he's doing, and that's a good thing from a contractor. If you seriously think he's trying to milk the contract, take a close look at what your escape clause looks like. Those things exist for a reason.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Um...I'd tell them to #sand. You're paying for a working product. On the other hand, "bug fixes" are are part of the dev process if it hasn't been released yet. They shouldn't have broken it out like that.
We won't sit down. We won't shut up. We won't go quietly away. YouTube, VidMe and My Mu[sic], Films and Windows Programs, etc. and FB
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
Assuming you (or your company) wrote the contract and agreed it with the outsourcer, then you should be able to see what you are supposed to pay for. Given that the developer is submitting a timesheet it would appear the developer is being paid by the hour, and bug fixes will likely be a standard part of his/her time.
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
He's "testing". And instead of just saying that, he expanded on it so the "invoice line" says something. The 16 hours is to be considered relative to the overall project. For a project that say lasts 2 weeks (i.e "8-10 man-days"), then 2 days "wrapping up and testing", is not unusual. "Testing", can involve multipl phases, depending on the size and complexity. I won't bore you, but they all have a place: unit testing, integrating testing, system testing, user acceptance testing. And frankly, when it starts to feel I spend more time filling time sheets, then I start to "lump things" on the report. Or, perhaps you think he should have gotten it "all right" the first time. Software development doesn't work that way when you're trying for the best overall solution. Think Boeing.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
Seems to me, having more data is better than having less. Perhaps knowing this type of information will influence decisions on future projects.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
A contract developer has mentioned the below on the timesheet : "Tested full workflow, identified bugs & fixed" - 16 hours. When we expect a module to be developed, and we are outsourcing it completely, the expectation would be to have it working out of the box. Don't know how these bug fix routines could be added to the invoice. That's how this works? This is sounding crazy to me. We don't outsource work much. Just learning these. I guess the contract document has to be tweaked.
In a word, yes, it's fair. If I were him/her and you complained about it, then I would simply lump that time somewhere else.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
He's mentioned on the "estimate" . 1.Development of module A - $x 2.Development of module B - $y Etc And we arrived at a $Z as an "estimate". The way he's billing on "testing & bug fixes" feels like it's gonna crash out this estimate. I think we should have spent more time on drafting the contract.
That is not a contract, as you say, it is an estimate. You need to expect the cost to over run any estimate when creating an application and testing, documentation and training are the areas that are usually not included in the estimate. Unless it is a trivial module then 16 hours seems to be a reasonable excess.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
GenJerDan wrote:
"bug fixes" are are part of the dev process if it hasn't been released yet
correct.:thumbsup: I guess the "estimate" model wouldn't work. They can arbitrarily stretch it to their favor. What if he adds 32 hours on a bug fix tomorrow? saying it's a tricky, critical bug? We dont want to get into how he introduced a bug & fixing it. It should be internal to him. A fixed cost deal would've been a trouble-free one.
Nand32 wrote:
A fixed cost deal would've been a trouble-free one
You have got to be joking, such contract requires a really detailed specification and the slightest variation becomes a negotiation on additional cost. Talk to the developer, build up a level of trust and honesty and work together to create a solution. If you cannot trust your developer then cancel the contract and move on.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP