Take the 2-minute tour ×

I'm fixing bugs for a software company as a contractor on a per hour basis (first time for me). Today, in 6 hours I fixed two issues which had been planned at 32 and 40 hours each. The days before (I've been working here a week or so) the pattern was the same.

I didn't plan time to fix those issues, and I didn't know what the issues were before signing the contract. I found a JIRA with all planned hours: some of those issues have been waiting to be worked on for years.

I signed a contract for two months, but I'm afraid I'm going to run out of work much sooner.

share|improve this question
Either tell them that you're worth 6 times the money you charge right now or take the rest of the week off. Your choice ;) –  blubb Aug 16 '11 at 14:04
Don't worry, there'll be a couple of issues that are planned at 6 hours each that will take 32 and 40 hours respectively. –  ChrisF Aug 16 '11 at 14:09
If those issues were planned at exactly 32 and 40 hours, then those were clearly very rough estimates. There's nothing unusual about an estimate being way off; that's why it's called an estimate. –  Kyralessa Aug 16 '11 at 15:15
Couldn't you spend a couple of weeks refactoring the code? That's what I'd suggest if you have nothing else to do. –  JB King Aug 16 '11 at 15:19
@ChrisF SO true. Makes me wonder who did the scheduling for the issues. And what they were drinking, and whether I can have some. –  Dan Ray Aug 16 '11 at 15:52
show 3 more comments

5 Answers

up vote 15 down vote accepted

You are learning an important part of IC Contracting getting a minimum guarentee. If they want you to guarantee your availablity to them for 2 months they need to be willing to guarantee you 2 months of work (or at least pay). While they can always find more work for you if they have no incentive they could decide that they can save a little bit of money by unloading your costs early. If you get the guarantee in your contract that will incentivise them to keep you working.

Take this as a learning experience and a reputation builder. Keep working effectively and do not ask if they want you to leave. Look to find ways you can help if you run out or low on tasks, and make the offer to help. Unless the project actually finishes early they will probably want to keep you around to prevent falling behind even if they do not have the workload for you that they thought they would.

share|improve this answer
Chad, good thought - particularly "Look to find ways you can help if you run out or low on tasks, and make the offer to help" –  Sandeep G B Aug 17 '11 at 5:00
add comment

Getting work done ahead of schedule is a great way to build a reputation as a skilled and more importantly, reliable developer. Keep up the good work and success will follow as your portfolio for fast, quality work expands.

share|improve this answer
Just make sure you considered time to track your hours, billing, documentation, testing, communictions (email saying I'm done), etc. –  JeffO Aug 16 '11 at 15:31
add comment

A few thoughts:

  • Was the planned time to fix shared with you or was it something you found? Do you know if the estimate includes additional effort that is outside the scope of your work? For example, some of my estimates include time for testers to test, final build and install package prep (amortized over several bugs), and other delivery oriented work. That stuff may not hit the developer, but may need to be accounted for in the paperwork.

  • I think that being honest is generally the right policy. Especially if you are in the work environment with other people, seeing you goofing off or intentionally slowing down will in no way give a good impression. As a manager of contractors, I will fight hard to keep around the guy that's working miracles... not so much effort is expended for the guy goofing off.

  • It's only the first week. I don't know if that's enough time to really know that ALL estimates will be ridiculously high. Frequently if an estimation system is off, it's off in both directions - so beware of that 4-hour bug that will take you 60 hours!

  • Before the end of the week, talk to your manager. Mention your concern about time estimates and your expectation that you'll still be employed for 2 months. Now is a good time to get temperature read on their level of commitment to you. Take a look around and find other areas of house cleaning - given that you are exceeding expectations, now's a good time to build new work for yourself - your credit should be high. It sounds like, if these bugs have been waiting around forever, there is likely some work you can do to add efficiency to their development processes.

  • It's also worth it to find out who's estimate this really is - just because a manager padded out the time to a week's worth of work does not mean that the development team thinks the same thing. It's worth it to ask around or ask your manager and see who came up with that number. Be careful about being critical, but finding out who has an unrealistic of bugfix times will tell you a lot about the company.

share|improve this answer
I don't know if that's only dev time estimate, but most of the issues are just bugs, so probably it is. –  Ando Aug 17 '11 at 6:10
add comment

Its ultimately a personal choice. You are well within your rights to sit at your desk playing minesweeper.

I personally would speak to the manger and point out that you have completed the two issues contracted already. I would then suggest I do one more "free" then leave it at that unless they want to contract out more work. That way you come across as great (having done ~120h work when paid for 80) and don't waste any time stretching out issues just to make them feel like they have got their moneys worth.

EDIT : Im assuming they allocated the budget to the project. If you did then you might want to reduce the cost to them. In contract its normal to overestimate by ~1/3. You overestimated by an order of magnitude

share|improve this answer
add comment

Additional question to OP: does you REALLY understood all the little details of the assignment? Sometimes the devil is in the details: a little word jumped on a fast reading can wreak havoc on your already done code. Maybe it's time to review the assignment to make sure you didn't forgot anything...

Beyond this, I agree that honesty is the best policy... I voted up both bethlakshmi's and the leo's answers (leo's with the Jeff O comment, which deserved to be an answer because is very important).

share|improve this answer
I refused to work on some of the assignments because they were vaguely described. This week they should come back to me with more details. –  Ando Aug 17 '11 at 6:20
@Andrea: Sometimes it's not about the descriptions. Sometimes it's about how your changes interact with the rest of the system (knock-on issues). –  Demian Brecht Aug 30 '11 at 2:36
add comment

Your Answer


