When a project has gone over the allotted hours, am I morally obligated to spend my own time fixing bugs or finishing the project?

I've been working about 20 hours per week as a C# programmer for about 15 months for the same company. I can only work part time because of a chronic disability and need to work from home. I'm also the only programmer at the company and am a 1099 contract worker (a 1099 contract worker is someone who is self-employed and works for another company). I've been doing C# for over a year after taking a 3 month intensive class. I had a background in programming in the early 2000s but wasn't able to work for a long time.

Sometimes I'm asked to quote time on client projects for things that I've never done before but I have to give a number so I give my best guess. I'm clear with my boss that this is just a guess. The last project I guessed at 80 hours but have now put about 110 hours into it. I'm not getting paid for the last 30 hours because the client doesn't want to pay for more time for the project. When I was at 80 hours the project wasn't completed yet. I went ahead and did the first 14 extra hours just because it needed to be completed. I volunteered to do this and wasn't asked to do it, only told that the client wouldn't pay for more hours. Then we ran into bugs that needed to be fixed and that took more time to fix those. There's been a lot of time testing the project also. I've also had to put 6 more hours into the project in the past couple days because I needed to figure out why things were running slow and how to speed them up. I feel morally obligated to fix the things wrong with the project I'm working on because I don't like putting out low quality work.

I think I've learned my lesson on this project but am not sure how to avoid the situation in the future of not quoting enough hours. I don't have the experience necessary to know how long things will take.

The good parts of the job are that I get to pick my own hours and prefer to work more second shift. My boss also lets me take a day off now and then when I'm not feeling that great. I do feel pretty lucky to have the job because most employers probably wouldn't hire a disabled programmer that can only work part time. I do get contacted by recruiters every week with lots of jobs but they are all full time.

I want to be a good employee and do a lot of other things like learning new technologies related to projects on my own time.

Some things about the job don't really feel right. I'm ok being on 1099 but I've consistently worked at the company for 15 months now. There's been a few times they have forgotten to pay me but make it up the next pay period. My boss has several LLC's and my paycheck kind of rotates coming from a different company depending on what project I am working on.

  • 116
    It appears you do not regard yourself as a full-fledged developer, and so you might be discounting yourself before your employer can beat you to it, and your offering to only bill hours that are forward-moving is a way to potentially appease your employer should they ever press this point. I doubt they ever will. You're a real developer and real developers get paid for all of the activities involved in development, including testing and maintenance.
    – Kent A.
    Commented May 28, 2015 at 5:19
  • 25
    what happens when you Guess 80 hours and finish the project in 60? Will you get paid 80 hours and the client billed 80?
    – Pieter B
    Commented May 28, 2015 at 9:49
  • 1
    @KentAnderson Spot on. I'm really confused why nobody mentioned billable hours, such as bugfixing after shipping the product when requirements have been met. Commented May 28, 2015 at 11:40
  • 1
    I would help to add that to the question to provide context for non USA citizens :D
    – llrs
    Commented May 28, 2015 at 15:27
  • 4
    Note: on the subjects of estimations, rather than giving a single number, you might want to give a range. For example, instead of quoting 80 hours, you would quote "between 60 and 180". The main advantage in a range is that on top of giving an "average" estimate, it also immediately conveys the degree of certainty. A 3-fold range (as above), clearly conveys that this is a wild guess. Commented May 31, 2015 at 13:42

15 Answers 15


When a project has gone over the allotted hours, am I morally obligated to spend my own time fixing bugs or finishing the project?

No. You are entitled to be paid for all of your hours worked.

Even if the project runs over the allotted time, even if your work is the reason why it went over, even if you feel bad - you should still be paid for your work.

Keep the stakeholders informed as the project progresses, and warn them if you see problems coming up that might cause you to go over the estimation.

And as you run out of allotted time ask them if they would like you to continue to fix bugs, or just to stop - it's their project, and their money, so they get to decide.

If this becomes a chronic problem, and you cannot estimate better, or produce work with fewer bugs, your job might be in jeopardy. Still, if you work, you should be paid.

  • If you always underestimate times by 50%, then the employer should really figure this out. "David said it will take 80 hours, so we base the contract on 160 hours. If it takes more than 160 hours we will complain to David". It's the employers responsibility to calculate what to charge.
    – gnasher729
    Commented May 28, 2015 at 15:34
  • 3
    @gnasher729 Unfortunately, the reality is that if you quote 50%, they will write the contract for that amount and hold you to it. I've never seen a business adjust a bid up, or take your higher range bid if you provided a range. (I have seen folks raise an eyebrow and ask, "Are you sure?" But if you're sure, they'll write it in, and hold you to it.)
    – Kent A.
    Commented May 28, 2015 at 15:58
  • I think you are incorrect because the OP is an independent contractor and thus working for himself and not working as an hourly employee of the company that pays him. He estimated the cost of the job based on his guess of 80 hours. Commented May 28, 2015 at 15:59
  • 5
    @HannoverFist And never did he make a commitment. The boss requested a estimate and he got one. The boss then (apparently) made a commitment to the client, but that's really not the programmer's responsibility (yes, it's important he communicates that this is just a wild guess and it might take much longer, and it is important that estimates do improve as time goes on, but none of that takes away that if you work on an per-hour contract, you should be paid for the hours you make, not the hours you estimated)
    – Jasper
    Commented May 29, 2015 at 9:24
  • 1
    And if the estimate is a good estimate there's a 50% chance he goes over it. If you're actually bidding you pad it somewhat! Commented May 31, 2015 at 1:06

Well you're not morally obligated to do anything, depending on your morals :)

If you look at the two ends of the spectrum, you have:

  • Fix them for free and then be expected to do so ad infinitum; or
  • Point blank refuse to fix them and (potentially) cause bad blood or even get fired.

Of course, this is if you only take the black and white approach. I would recommend a compromise approach where you put bounds on the amount of additional bug fixing you are prepared to do. For example, identify one or two critical bugs or issues that can't be lived with, and agree to fix those. If there are other less priority issues, they could be addressed at a later date when you perhaps more budget.

This approach forces a bit of thinking by your employer as to what REALLY needs to be done, and then you can look at building more buffer into future quotes to fund any issues that arise through the testing cycle.

  • 31
    As programmer I'd like to add this: There are bugs which are result of sloppy work. If there are bugs which you should've caught with basic testing, I'd fix those too.
    – Martijn
    Commented May 28, 2015 at 8:37
  • 18
    You also have to be wary of 'bugs' that are the result of a client changing their mind, or wanting something new. These should always be paid for. Commented May 29, 2015 at 7:34
  • 1
    There is yet another thing I'd add here that all responders have missed. (can't respond myself??) It's that if you are the single programmer, it means your client cannot easily replace you. And that means that you should be raising your rate until you stop feeling that you have over-worked on the project. Regarding whether you should fix the code, you should consider you'll be working on this code tomorrow, so my philosophy is to just fix it now and bill higher later. And regarding morality, even if the bugs are completely your fault should be irrelevant towards your ultimate pricing!
    – Agamemnus
    Commented May 30, 2015 at 4:38

It sounds like here that the company has made a fixed price bid to the customer based on your estimates and now things have run over they are refusing to pay more. This is a common scenario and if the company isn't big enough to swallow the disparity then usually you'll be expected to provide the time to finish it. Whether you should is down to you, but the expectation will be you should, so if not be prepared for the fallout.

The thing about fixed price working is you MUST take into account potential unknowns and bugs as part of your estimate. So you need to pad any time (I'd normally add a third for work/technology you know, which seems closer to the actual time in your scenario, but in your case probably 45%).

Not delivering will be an issue, and your estimates will be held against you so you need to practise this.

Search for three point estimation on Google, you'll find spreadsheets you can use. For this you estimate best/worst/likely times for each task and the spreadsheet should give you a 90% likely estimate (where best is only 50% likely). In blind tests people asked to give an estimate, then best/worst will always be over optimistic and give a number closer to best.

Plumbing your numbers in as follows:

  • best 80 hrs
  • worst 120 hrs
  • likely 110 hrs

Gives 113 hrs with 85% confidence up to 126.67 hrs with 99.5% confidence (note higher than worst case due to the range of the estimated times).

  • The best thing about this best/worst/expected approach is that you should be identifying the factors that would cause the best and worst cases to happen. If your contract arrangement accommodates it, you can then incorporate those conditions into the contract. Additionally, if the client thinks the estimate is too high, you can show them what factors would cause the best case to happen, and try to get them to agree to those contractually.
    – Kent A.
    Commented May 28, 2015 at 12:18
  • 12
    This is very similar to how we do things at my company, and it serves us well. But the moral of the story is to never go into a contract without setting expectations first for who is responsible when things don't go as planned. Somebody has to eat that cost, and if it's going to be you, that should be established ahead of time.
    – thanby
    Commented May 28, 2015 at 13:15
  • 2
    "three point estimation on Google" Commented May 28, 2015 at 13:48

It depends on what type of contract you're working under. If your contract is for a specific task, quoted/estimated by you to be done within a certain amount of time or at a specific price (often called a fixed-price job), then you are taking on the risk of the job requiring more time. In such a contract, you should be making it clear that any changes to the original plan are out of scope, and must be negotiated separately. You cannot afford to take on infinite risk. In reality, folks working under such contracts often absorb small changes, to a point. Conditions you cannot absorb should be agreed to as part of the contract.

If you are a contract employee, simply because they want to pay you on a 1099 rather than a W2 (assuming you're in the USA since you mentioned 1099), then the company is the one who should be assuming the risk of taking longer than expected. You should be paid for the hours you work -- they have the moral obligation to pay you for it.

Regardless of which kind of contract you're working under, you owe it to yourself and to your employer to do a better job of estimating. It doesn't help anyone to simply provide a number you think will make them happy, but isn't based in anything substantive. As a developer, you need to be tracking the time you spend on the projects. You should keep this in a file or spreadsheet that you can pull from when doing future estimates so you can know how long certain tasks take. Estimating is part science and part art. If you don't track anything, you remove the science part, and you're just relying on art, and that doesn't seem to be working out for you very well so far.

It doesn't have to be elaborate. You can simply say something like Add feature X to application Y: 127 hours. If you go one step deeper it might help you with other jobs that are not quite identical, but similar (for example, GUI updates: 20h; Backend updates: 37h, Unit tests: 40h; Integration tests: 20h; User docs: 10h).


Your employer is obviously trying to rip you off.

Your employer has a contract with a client. The client wants a job done, your employer quotes a price for that job. It is your employer's responsibility to deliver (depending on the contract, obviously). Whether the employer makes money or not is not your problem.

The employer has asked you as an "expert" to give an estimate how many hours this job would take. You told the employer you haven't done this kind of work before, but gave a quote anyway. It was up to your employer for how much payment to ask. They knew that they didn't have a reliable estimate.

Unless you signed a contract to deliver this project in 80 hours, or for some fixed price, your employer must pay you for the work done. Of course the employer can decide to fire you, but nevertheless must pay you for the work done. It is perfectly normal that bugs will be found after a project is delivered, so if you fix the bugs, you need to be paid for the time fixing the bugs as well.

Your employer will (hopefully) have taken your estimate, added some percentage to keep the risk low, and added some profit. The extra money he pays you would come first out of the added percentage to keep the risk low, and then out of his profit. That's how it works.

  • 4
    I agree. The fact that the employers "have forgotten to pay" the OP on occasion would seem to back this up. Commented May 29, 2015 at 2:34
  • Oops. Avoid putting intention into the equation before you know. It might be, and sure sounds like it, that the employer simply is unused at doing this kind of work. So, it is not necesserily that they are trying to do a rip off.
    – ghellquist
    Commented Jan 25, 2018 at 17:18

Testing and fixing bugs is part of the software development process. e.g. When you buy a car, it has been put through all sorts of safety checks and any checks that failed have been fixed. Those fixes cost the company money and they have passed those costs on to you.

Perhaps you could blame yourself for not considering this in your quote, but not only did you teach yourself a lesson here, your boss is teaching you a (bad) lesson. i.e. to always estimate more time than you think it will take.

I am curious, if you finish a job in less time than expected, e.g. let's say you finished the job in 60 hours, would you still be paid for the 80?


Sometimes I'm asked to quote time on client projects for things that I've never done before but I have to give a number so I give my best guess.

The source of your problems indicated in bold above. You need to supply something a lot closer to a worst-case estimate. If it turns out to take less time, no harm done.

When a project has gone over the allotted hours, am I morally obligated to spend my own time fixing bugs or finishing the project?

It depends on the arrangement. If you're paid by the job, you have to finish it to get paid. If you're paid by the hour, you have to get paid for each hour you work. If you're paid by the hour, but only up to a maximum number of hours, you must finish the job to get paid, but if it turns out not to take the maximum number of hours, then you get paid less the faster you work. This last category sounds like the kind of arrangement you are in, and it is the worst kind to be in. Depending on how much job stability you feel you have, you may consider talking to your employer about migrating to one of the other arrangements.

  • 2
    That said, if you're paid for the job, you ask for a much higher hourly rate, because you need that to cover the risk. That estimated 80 hour job should pay at least 120 hours worth of work, so up to 120 actual hours you still break even, and only after that you lose out.
    – gnasher729
    Commented May 28, 2015 at 15:31
  • @gnasher729 I don't get what you're saying. If you're paid for the job, there is no such thing as an "hourly rate" for that transaction.
    – Atsby
    Commented May 28, 2015 at 21:10
  • @Atsby Usually when you quote a fixed price job, you quote a dollar amount made up of the estimated hours X hourly rate. If the real job is going to take 120 hours, you need to either say 120 hours in your quote, or adjust your hourly rate so that the additional money X 80 hours still pays you what a 120 hour job would have paid. Most clients want to see more than just the bottom line in a quote - they want to see their cost broken out. If you're dealing with large companies, they won't entertain your bid without the details, especially the hourly rate.
    – Kent A.
    Commented May 29, 2015 at 5:19
  • Cont'd... Most large companies will balk at an obviously inflated hourly rate, and may even have established limits as to what they can accept as an hourly rate. So your best bet is to do a good job of estimating, and then add hours to compensate for the risks.
    – Kent A.
    Commented May 29, 2015 at 5:22
  • 1
    @KentAnderson The only ethical thing is to not do business with such companies. I think there are plenty out there that don't need to see an hourly rate underlying the figures, or can handle your hourly rate. In any case, it's hardly ethical to pad out the estimated hours required for the project in order to "work down" to a common denominator skill level that everyone is expected to bid at.
    – Atsby
    Commented May 29, 2015 at 5:31

Don't think of it as a moral obligation. Think of it from the perspective of "part of a whole." You were hired into a company to do a job. That job comes with a set of responsibilities. You will be expected to uphold those responsibilities.

It sounds like your company is in the classic situation where they underbid a task. There will be pain, the question is to whom it is applied. It sounds to me like they took your estimate, and portrayed it as a quote. If so, they need to understand that their actions were responsible for the issue at hand, and they should be expected to be found culpable.

The question of whether "fixing bugs on your own (unpaid) time" is in the responsibilities is one to determine between you and your employer, but you should never sell yourself short. You must be compensated according to what you worked. If they wish you to fix the code on your own time, and it takes you an extra 30 hours to do it, that needs to be accounted for in one way or another. Each company handles it differently. However, there is one foolproof way to handle this: Instead of thinking in terms of hours worked vs. hours paid, treat it as though you were paid for all worked hours, but paid less per hour. In this case, you worked for 110 hours at a rate of 80/110 * {your nominal wage}. Is this wage rate acceptable to you? If so, then you should probably do the extra work, because you are likely being paid for the risk. You should also account any non-monetary compensation you receive (stock options, free day care, etc.) to get a holistic picture. If the wage rate is too low (it puts you well below the wage rate of comparable jobs in other companies), that suggests they are not paying you for risk, and you should not be expected to shoulder it.

Another consideration which factors into whether you accept the wages as they are: if you had finished the task in 60 hours, would you have been paid for 80 hours? Somebody takes the risk for uncertainty, and it usually works best if that person is the one who also receives the reward for uncertainty. If you were paid for the task, rather than for the hours, you have to complete the task per the contract.

Failing that, eat the 30 hours. Someone has to. On the next task, substantially overbid, explaining that your estimate is an upper bound on the cost. A mistake that costs you 30 hours of your life is actually a relatively cheap mistake in the great scheme of things. However, you should respond, and if the response is "I'm not making anything except upper bound estimates because the company turns my estimates into quotes" I think that is a highly rational solution.

Ideally, though, this should be a discussion, not a set of threats. You want to be partners with your boss, not antagonists. However, whoever your boss is, they do need to understand that all actions have consequences, and if their actions put you in a tight place, you will naturally defend yourself against their potential actions. That is the story of society. It's not new, and it's not going away.

The discussion is important because it keeps options on the table. They may be in a position where they have no process for compensating you this time, but can come to an agreeable solution for handling future occurrences. Perhaps they repay your unpaid work with equally unpaid non-monetary incentives. Value does not always have to come in the form of dollars.


Rather than repost, I would rather reference the discussion here, good food for thought: Ask HN: Getting stressed out moonlighting

Some nice points in there in dealing with clients, learning to say no, giving clear boundaries, etc.

To add my own comments, I would suggest going forward you make it clear to yourself and them what the exact contract is. i.e. if you are working on an hourly basis and any overrage will be billable. This includes bug fixes, etc. Even for major million dollar projects done by consulting companies such as IBM and Oracle there is slippage, and the client usually has to pay for it. It happens and it's not necessarily your fault. So clarify upfront how you want to work with them.

If they insist you must stick to the estimate and include free bug fixes, you should start doubling your estimate to add some buffer room, and then ask them for a maintenance contract where they pay you a fixed price every month to take care of any issues that come up and to compensate you for analysis and investigation time.

  • 2
    Consider summarizing some of the key points from the discussion, as a backup in case the link source is moved/deleted.
    – mcknz
    Commented May 28, 2015 at 15:20

If you're an indepedent contractor then your client is the company that has engaged you, not necessarily the ultimate user of the product. Based on some of the things you've said, like they allow you to have a day off, you may not actually be an independent contractor. If you haven't already, I'd view the IRS definition of an independent contractor.

As to your original question, it all depends on the terms of the contract; but if they've engaged you to provide working software I would say that's what you are obligated to provide. I hope you have better luck estimating next time.

If you are going to work as an independent contractor any way, why not consider applying for some jobs on an outsourcing website to gain a little more control over the terms of your provision of product?

  • +1 for identifying the probable violation of the independent contractor definition. On the advice to try getting some work through an outsourcing site, it is likely to cause OP more of the same headaches until he gets better at estimating.
    – Kent A.
    Commented May 28, 2015 at 12:10

There seems to be a consensus that you should get paid for all hours worked. I agree that you should get paid for all hours your employer agreed to pay you, but you told him that it would take 80 hours to "complete" the job. In my opinion, an application with bugs in it is not complete. Then again, I don't know if it is ever possible to deliver a completely bug-free application. Regardless, it is an error on your part for not estimating accurately. Though there seems to be a lot of issues here, I think you are obligated to fix the bugs.

Next time you should add in time for bug fixes and testing. Also, next time if your employer is smart, he'll add some time on to what you told him as well. I'm sure this whole situation might have put him in a hard spot too.

I have a question as to what these bugs are... if they are actual bugs that cause the app to not do what is was supposed to do or if they are things they want to add to the program. My boss will sometimes say something is a bug when it really isn't, like "this doesn't sort properly" when it sorts the way he asked it to in the fist place. Make sure you're not getting requests to add features not in the original specs.

Also, it seems to me if you are a contractor not actually working for the company, you should be able to take off whenever you please. As long as the work gets done by when it is supposed to be done then it shouldn't matter when you're working on it - what day or what part of the day.


At 20 hours per week, you hit 80 hours in 4 weeks and knew you were not finished? This is when everyone needs to be informed (Ideally, you should informed them after 40 hours that you were no where near half-way completed.) and decide the following:

  1. The client can approve to pay for more hours.
  2. The company pays for the extra hours.
  3. You work the extra hours for free.

There are no guarantees in this life, but as a client, I would not wait for you to tell me after-the-fact, that you've added another 30 hours and expect me to automatically pay.

You can only learn from the experience:

  1. Deliver bad news as early as possible.
  2. Your estimates/quotes should be in a range 70-100 hours as an example for this project.
  3. Get an agreement by all parties on what to do when you go over-budget.

Based on everything you've said about your situation, I doubt you're charging at the high-end of the consultant scale. There are probably other programmers you under-bid. Often those who charge less have less experience, so the customer should beware that projects will take longer, estimates are less accurate, there will be some on-the-job learning.

You were an inexperienced programmer put on a project all by yourself, so your manager mitigated his risk by not paying you.


There are several issues here.

One: Are you an independent contractor or an employee? Typically if your income is reported on a 1099 you are a contractor, but sometimes companies report pay this way for tax purposes, and both the company and the worker think of him as "really an employee". The IRS has rules that say that even if your income is reported on a 1099, you may be a "statutory employee" if you are basically treated as an employee and not as a contractor, regardless of whether pay is reported on a W-2 or a 1099.

Two: I'm assuming you're not an employee in any sense, but just in case, let's quickly cover that case.

If you are an employee, than are you hourly or salaried? If you are hourly, then you should be paid for hours worked. If a project takes longer than expected, that's too bad for the employer, but they still have to pay you. I don't know what country you're in, but in the U.S., an employer is required by law to pay hourly employees for all hours worked.

If you are salaried, you should be paid a fixed amount per week or per month or whatever schedule, but not necessarily per hour. If you have to work 60 hours this week to get the job done, too bad for you. If this week things are slowly and you only have to work 30 hours, cool, take some long lunches and leave early. But they have to pay you regularly. They can't pay you when there's work to do and not pay you when there isn't. If that's how it works, you are being treated as a contractor and not an employee.

So, three: If you are a contractor, this depends on what was agreed to up front.

Typically in this business, there are two kinds of contract: "time and materials" and "fixed price". In a time and materials contract, you tell the client how many hours you think the job will take, but they pay you for the actual number of hours worked. If you take fewer hours than you estimated, they pay less; if you take more hours, they lose money. In a fixed price contract, you quote a fixed price, and then that's what they pay you, no matter how many hours it ends up actually taking.

Thus, in a time and materials contract, the client is taking the risk that the project may go over the estimate, In a fixed price contract, the consultant takes the risk. Normally when someone offers a fixed price contract, they give a high estimate, that is, they give an estimate based on the assumption that many things will go wrong, rather than a best-case estimate.

All this should be clearly laid out up front so both parties know what they're agreeing to. Preferably in a written contract signed by both parties, so there is no confusion. It sounds like you haven't done this in this case. That puts you in an awkward position.

My advice would be this:

(a) In the future, get this spelled out up front and have a written agreement.

(b) As it's too late to do that in this case, I'd suggest that you tell the client that the project is going over time, and as you did not have an agreement in place saying whether this was fixed price or time and materials, you propose a compromise: You will bill at a reduced rate, maybe 50% of your normal rate. Or quote something higher than that and let them bargain you down to 50%.

If you let the client pay you only for hours worked when a project comes in under the estimate, but only for the quoted number of hours when a project comes in over the estimate, than you are letting them take advantage of you. It's not fair to say they get all the benefit when things go well and you get all the penalty when things go badly. If those are the terms the client demands, then I'd be sure to estimate high and not let them bargain you down on that. Of course all of this comes down to how much you need the contract. If you have 50 clients waiting in line, you are in a position to make demands. If you only have one potential client and your rent is due and the refrigerator is empty, you have to be prepared to give in to get the contract.


This is a perfect illustration why estimating in terms of time is a bad idea.

The problem is that it's very difficult to estimate exactly how long something is going to take you because not only is it hard to estimate your own time, it's impossible to estimate the time it will take for other people whom you depend on. Does your estimation take into account the fact that that person who you are reliant on is taking a day off next week just when you need them? Probably not.

Also, a developers idea of time may well be different from that of other people. When a developer says something will take them a day to do, they probably mean that it would take them a day if they didn't have anything else to do; but inevitably they do have other things to do - they have meetings to attend, code reviews to do, giving help to other devs etc. The work might take 8 hours to do, but that will be split up over a couple of days, perhaps. A stakeholder, however, might take a day to mean that they can expect the finished article tomorrow.

If you're absolutely forced to estimate in terms of time, my advice is to make the time as long as possible. Ideally, though, don't estimate in time; estimate in terms of complexity, as is recommended in most Agile methodologies.

  • I find that "hours required" is the preferred type of estimate for most people who contract/employ developers. Personally, I prefer that people come to their own conclusions about budget and timeline, based on their presumable superior knowledge about their requirements in these respects, and ask me if I can work within their constraints. Rarely are clients/employers able to do so. To your point about definition of time, it is always a good idea to provide both the hours required and the schedule.
    – jiheison
    Commented Jun 5, 2021 at 16:22
  • I can't say I've encountered that. As a developer for 10 years and a contractor for 7, I've generally found that estimates be done in points rather than in time. I'm based in the UK, which may make a difference. Points obviously can be translated to time, but at least the developer can't be held to a specific timeline as the OP was. Commented Jun 5, 2021 at 20:12
  • Most of my work is for clients and employers who are not implementing Agile in their own businesses. They want estimates in units that they are comfortable with, which is cost as a function of hourly rates and dates on a calendar. As you say, I could develop a points-based estimate and translate it to hours. This may well produce better estimates. But I am still on the hook for that number of hours and whatever associated deadline was agreed to (subject to any subsequent negotiations).
    – jiheison
    Commented Jun 5, 2021 at 20:35
  • This sounds like a model where you are directly employed by clients, in which case you're directly in control of the product and you don't have to attend to the other company business I alluded to. This is not my experience, and doesn't sound like that of the OP either. Commented Jun 5, 2021 at 21:31
  • It is true when working directly for clients. It is also true for software shops where management does not effectively intermediate between clients and developers (and I have worked for my share). Since OP noted that they were "told that the client wouldn't pay for more hours", I suspect the latter.
    – jiheison
    Commented Jun 5, 2021 at 21:42

There are excellent answers here already, so I'll just add a bit of advice: look into Test Driven Development, aka TDD.

Basically, the technique consists in cycling the following steps:

  1. write automated tests for new functionality ahead of actual coding of said functionality. The tests should reflect the specifications.
  2. run the tests (they obviously will fail, since the code isn't there yet)
  3. proceed with the implementation...
  4. run the tests again and correct the implementation until they pass.

Practice it for a while and get a sense of how much overhead it requires. Build that extra time into your estimates.

The test suites you gradually develop in the process are now part of your "safety net". You can run them again every time you alter product sources, as regression tests. Moving forward, this significantly reduces risks of surprise bugs occurring at the last minute or after deployment in production...

  • 4
    This is good advice, but is not really an answer to the question. Consider including an answer in addition to the advice.
    – mcknz
    Commented May 28, 2015 at 14:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .