purely by experience. been there done that.
you ask for something, I know about how long that will take, and then I double it.
Ask HN: Developers, how do you estimate projects and write proposals?
71–80 of 109 posts
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#72Badly
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#73I don't estimate, I work the other direction. How much is it worth to fix? That's a much easier value to discover. From there work backwards to determine how much to spend and where to prioritize. Eg: a bug generates 3 email and 3 phone support issues per day, at a cost of 1h or $33/day - $12k/yr. Easy to justify spending one dev-week on the issue ($6k). Or missing feature that lost a sale of $50k easily justify $5k…
Funny, I find measuring opportunity costs much much harder than measuring engineering effort. Even in your example, are those phone calls the substantial costs, or is it customer confidence in your product being lost the main motivation you should do something with the bug? If so, what's the dollar value of this confidence? Also, do you have monitoring good enough in place to see how many customers are hitting the pr…
A lot to respond to, I'll try.
I'm measuring stuff that is actually happening, whatever it is (phone, email, error log, metrics, etc) and have to assign a cost. I find that easier than guessing how long to discover the right answer to a (maybe) complex problem.
For phone and email support it's easy, directly measurable cost. One would decide for them selves how to factor those intangibles (ie: confidence).
Currently I do things like this-ish: - Phone and email at direct cost; but if the issue is a duplicate double cost. - Lost deal factor at 15% first year value - Logged errors at $10/first, $2/dupe - make values that match your company revenue/expense.
We try to exit interview clients but generally have a good feel for it - ours is a pretty high touch relationship
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#74Lots of great answers here - but something I wanted to focus on is doing a risk analysis alongside the estimates. Places where I have worked have generated corporate estimates for clients (usually in a competitive bidding situation). One of the sign-off decision points business enforces on the bid teams is to check that they have considered risks to the project, possible impacts in terms of time and cost (usually related), and a risk budget (e.g. for extra days for rework) which depends on the magnitude and probability of the risks. Risks are usually expected to be higher if the work involves any sort of novelty. If risks don't manifest, the business makes more profit, but if they do the PM has a basic safety reserve. The need to keep estimates competitive generally creates pressure to force the risk budget down, but the fact that the process is subject to business scrutiny and independent internal review can lead to mature debate about the issues.
The key to this process working is to have a tech assurance function that is independent of the bid team and their management, and that the overall company accepts the process. The assurer can say to the business "I think you are pricing this too low for the risks involved" but it is specifically not the reviewer's call as to whether the bid is submitted or not, so management can still submit the estimate if they want to. But, if things subsequently go south, the blame isn't immediately passed to the bid team or the delivery team.
Alternatively, generate an estimate, round it up to the next order of magnitude, and double it.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#75TL;DR: Lock down the scope before providing estimates. Always double your estimate because developers are damagingly optimistic about their ability to get things done.
Slightly longer version: If the scope isn't locked down at a granular enough level, one where each unit of work would take no more than one day, then you can not trust the estimate.
If you as a developer provide or agree to an estimate before the scope is locked down, then you're doing this at your own peril. That estimate will be used against you at every opportunity. It will be used to pressure you into working for free (overtime isn't usually compensated for in full-time positions). Your personal relationships or chances of getting into one will suffer. You'll begin to hate the people you work with. You'll get fat and / or ugly. Remember Milton? Never forget Milton!
Being asked to provide an estimate prior to scope is more of a negotiation tactic than a serious attempt at accomplishing valuable work. If you thought you were making $x for y hours of work per week, well guess what?! Because of your premature estimate, you're now making $dx where d is less than one and hopefully above zero.
Okay, so lets say that you were able to lock get the scope locked down. What now? Now you can provide an estimate by adding up the estimates for all the granules of work you'll be doing and then you'll want to double that number. Why double? Because most developers are incredibly optimistic about their ability to deliver quality code. You're probably not adequately including time for QA and changes anyway. The last 20% of any project often takes 80% of the time, so double those estimates.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#76Somewhat heretical, but I generally don't. I usually explain that development is an iterative process, and that I generally deliver work as soon as it's done. We talk about the knobs that are available to tune the work to the goal, and how to measure goals. We talk about containing costs, and working together to deliver good value. I find that in general, estimates are rarely, if ever, accurate to any significant deg…
This sounds great. How the hell do you get customers to buy into it though? I often wind up falling into this sort of situation with old customers once they're confident in my work and fairness. But for new customers, how do you tell them "don't worry about how much this will cost or how long it will take"? How do you build that in a contract?
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#77In my experience, whatever you think is honest and accurate, triple it. And whatever you think is a fair price, double or triple it.
A proposal doesn't need to be done in a special tool. It's a simple document that outlines what will be done. I've personally used notepad.exe at times. Always send the proposal, estimates and payment terms before even starting any work. If it is a larger project, you can charge for the proposal itself.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#78Somewhat heretical, but I generally don't. I usually explain that development is an iterative process, and that I generally deliver work as soon as it's done. We talk about the knobs that are available to tune the work to the goal, and how to measure goals. We talk about containing costs, and working together to deliver good value. I find that in general, estimates are rarely, if ever, accurate to any significant deg…
I find estimating dishonest too. I tell clients that a project becomes late 'one day at a time' and that the higher clarity there is in the objective, the more creative we can be about trying to solve the problem. so there is less work to undertake to reach it.
I don't think a developer's salary is high enough to justify taking on any moral risk on the basis of estimation of any project.
In Australia, even the highest budget software projects have major cost and time blow-outs, often in years and often in 100s of millions of dollars. If this were a solved problem then this would not be the case.
I think the best thing you can do is retrospective analysis of work completed for a given individual and a team, and use that to project, but I am yet to find a client who is vaguely interested in such a thing, e.g. Joel on Software's Monte Carlo estimation solution [0].
I'm cynical because it's early!
[0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#79I don't estimate, I work the other direction. How much is it worth to fix? That's a much easier value to discover. From there work backwards to determine how much to spend and where to prioritize. Eg: a bug generates 3 email and 3 phone support issues per day, at a cost of 1h or $33/day - $12k/yr. Easy to justify spending one dev-week on the issue ($6k). Or missing feature that lost a sale of $50k easily justify $5k…
Funny, I find measuring opportunity costs much much harder than measuring engineering effort. Even in your example, are those phone calls the substantial costs, or is it customer confidence in your product being lost the main motivation you should do something with the bug? If so, what's the dollar value of this confidence? Also, do you have monitoring good enough in place to see how many customers are hitting the pr…
I think in the first example it's easier to calculate based on the time spent vs the salary + overheads of the employee(s) dealing with the issue.
If something took up one hour of my day and I could spend a week one-off to reduce that to 0 hours a day, that's a no brainer.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#80(about estimating - I don't tend to write proposals) You could have a look at https://www.estigator.com (NB it's a half-finished side project right now) I'm no longer a contractor, although I have been, and I'm frequently asked by my new employers to provide estimates for dev tasks. Trouble is, businesses/clients tend to see an estimate as a promise, or a target. From the developer's point of view it is hard to do an…
The concept behind this is great, especially since this very closely matches how I usually estimate things — lower bound and highest expected bound, currently the user experience is pretty meh since you need to add a line and remove two lines to get additional "between N & M units" lines, but I can totally see myself using it once it matures. Would also recommend to others once it matures.
Do you have a newsletter or something similar to subscribe to for releases?