5 ms·

Tell HN: My rule of thumb for initial estimation

I think it was Fred Brooks Jr in "The Mythical Man Month" who said that when planning a project he spent 1/3 of the time on design, 1/6 of the time coding, 1/4 of the time on component testing, and 1/4 of the time on system integration and testing. I've found these estimates to be remarkably accurate and use them all the time. If I think something will take a day of coding, it usually takes a week of work to get it properly done. That's not one day from midday Tuesday to midday Wednesday because I turn it into 3 mini-projects and run around the design/write/test/integrate cycle as fast as possible, but it's a surprisingly good predictor. I now use it when estimating other people's work. If they say it will take a day, or a week, I multiply by 6. If they say it will take a month, it'll never be done. Unless they're using the same rule ...

cperciva 16y ago
My strategy is to estimate the number of LOC and estimate 1 month per 1000 LOC. I tend to slightly underestimate the number of LOC, but I average slightly more than 1000 LOC/month, so it tends to work pretty well.
- tomjen3 16y ago
  That might work for a project, but I guess the number of LOC you can write in any given time depends largely upon which language you write it in.
  - thibaut_barrere 16y ago
    Some projects involve a lot more infrastructure work than coding. Typical example (my current project): setting up a resque/redis queue monitored by god/monit with a simple sinatra front-end (that is less than 100 lines long). A large part of estimating errors comes from forgetting an area that requires work (eg: in code, deployment, documentation, staging/feedback/iterating...).
gte910h 16y ago
Check out "Software Estimation: Demystifying the Black Art". It's full of great light and heavyweight techniques I use all the time in my day to day running a fixed fee software development company (which basically thrives or falls on the quality of our estimation and the risk pricing to go with it).
grigy 16y ago
Joel Spolsky has a great article on software schedule estimation - http://www.joelonsoftware.com/articles/fog0000000245.html http://www.joelonsoftware.com/articles/fog0000000245.html. I found it useful and learned lot from it.
HeyLaughingBoy 16y ago
Sounds about right, although I'd bundle collecting & verifying requirements in with the 1/3 time for design. When you say "a day of coding," what fraction of a normal workday are you able to spend actually writing code?
thibaut_barrere 16y ago
I don't multiply by 6, instead I use various techniques that works quite well: - http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning http://www.mountaingoatsoftware.com/books/1-agile-estimating... (with free chapters; also read the various presentations on the site) - http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351 http://www.amazon.com/Software-Estimation-Demystifying-Pract... One key point is to really understand what is risky in terms of estimating (either technically or politically or because it's too vague). At some point, you can really become accurate as long as the scope is well understood. In my case, the Fred Brooks technique does not apply: my last customer iteration was 70% infrastructure, 20% code, 10% pm. The one before was 70% code, 10% infrastructure, 10% documentation, 10% pm.
drbaskin 16y ago
I've heard the following rule about writing (math -- other fields may be different): Take your best estimate, double it, and then increase the units. For example, two days becomes four weeks, one week becomes two months, etc.
dugmartin 16y ago
I always liked the following method: double the estimate and then go to the next larger time unit. So, one hour is two days, 4 days is eight weeks, etc.
- frankus 16y ago
  Calendar time or billable time? That's probably pretty spot on for converting from the latter to the former (assuming you're honest and don't bill for things like time spent reading HN).
fara 16y ago
Beware of Parkinsons Law: "Work expands so as to fill the time available for its completion."
wilhelm 16y ago
I start with the number of hours it would take me to create something if I was continuously in the flow, motivated and inspired. Then I multiply by π. The results are surprisingly accurate.
rw140 16y ago
Generally I don't get asked for an estimate until after I've done the design, so these numbers are code, unit test and very basic test on real hardware only. These are the rules I use: - If I think I understand everything it involves, then I take my estimate for all the bits, add them up and multiply by 4. - If I think I understand everything it involves, have done something similar before, and gone through my list of things to do a couple of times looking for stuff I've forgotten, I can multiply it by 2 instead. If I'm unsure how long something will take I am never allowed to round down. - If I find myself sizing something with the word 'just' in the sentence, I'm missing something big. (e.g. Then it's just a matter of recreating the error condition and making sure my error gets triggered correctly.) - If I'm not almost finished (i.e. functionality working with some hacks, unit test passes) by halfway through the time then I'm going to miss my deadline. - I am still mystified as to where that other half of the time goes (I have a proper 90% rule going on), but some of it is getting my code in a shape where I'm happy about checking it in - dealing with comments so they mean things to people other than me, removing ugly bits of code, checking with co-workers in places where I wasn't sure I'd made the right decision. My maximum speed on this is about 500 lines a day. Some more time is then spent getting things back working again, because I'll have broken things in the process. And I need at least a day to get a sandbox build behaving properly, and willing to run on my hardware. edit: formatting
robwgibbons 16y ago
Our team can attest to these estimates. Visual layout and design is by and large the most time consuming part of building a website. Code is easy once you know what you're doing.
briandoll 16y ago
How about doing it the other way around? How much value do you think a certain feature is worth? How much time should you spend producing that feature, as relative to its value? Then, figure out a way to ship a viable implementation in that amount of time. There are many techniques for estimating how long software development tasks will take primarily because they all suck. Estimating takes time, and is almost always wrong. Some people even advocate figuring out how off your estimates are, to improve your future estimates, so you can be a better estimator. What? I think it's best to stop estimating and start shipping.
- RiderOfGiraffes 16y ago
  You're clearly in a different business to mine. Someone comes and asks me how much a feature will cost I'd damn well better be a good estimator, because it's usually a fixed price contract for someone with flow-down penalty clauses. In short, sometimes estimation matters. Knowing when it does and doesn't matter is a different question and a different skill. Perhaps for you it never matters, but before you diss someone as heavily as you just did, I suggest you consider that some people have different circumstances than yours.
  - briandoll 16y ago
    There is just so much lost in that phone-tag of a conversation between the actual customer and the actual developer in the scenario I think you're describing. Agile estimating techniques seem to provide a reasonable level of expectation, while placing more importance on collaboration between the product owner and the developers. Once you add development managers, project managers (who are often re-estimating for you, adding or reducing a number to align with some other expectation) and a product owner who's only hearing numbers rather than the details, it's a very lossy conversation. How many estimates have you given where you wish you could have said "but if we just do it like this, it'll only take x% of the time", and how well was that communicated to your client? I just think software estimating as a way of holding a conversation about a product under development is unproductive at best, and often leads to an inferior product .
mrlyc 16y ago
What works for me is to estimate how long a project will take if there are no major problems, then double it.

cperciva 16y ago

My strategy is to estimate the number of LOC and estimate 1 month per 1000 LOC. I tend to slightly underestimate the number of LOC, but I average slightly more than 1000 LOC/month, so it tends to work pretty well.

tomjen3 16y ago
That might work for a project, but I guess the number of LOC you can write in any given time depends largely upon which language you write it in.
- thibaut_barrere 16y ago
  Some projects involve a lot more infrastructure work than coding. Typical example (my current project): setting up a resque/redis queue monitored by god/monit with a simple sinatra front-end (that is less than 100 lines long). A large part of estimating errors comes from forgetting an area that requires work (eg: in code, deployment, documentation, staging/feedback/iterating...).

gte910h 16y ago

Check out "Software Estimation: Demystifying the Black Art". It's full of great light and heavyweight techniques I use all the time in my day to day running a fixed fee software development company (which basically thrives or falls on the quality of our estimation and the risk pricing to go with it).

grigy 16y ago

Joel Spolsky has a great article on software schedule estimation - http://www.joelonsoftware.com/articles/fog0000000245.html http://www.joelonsoftware.com/articles/fog0000000245.html. I found it useful and learned lot from it.

HeyLaughingBoy 16y ago

Sounds about right, although I'd bundle collecting & verifying requirements in with the 1/3 time for design. When you say "a day of coding," what fraction of a normal workday are you able to spend actually writing code?

thibaut_barrere 16y ago

I don't multiply by 6, instead I use various techniques that works quite well: - http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning http://www.mountaingoatsoftware.com/books/1-agile-estimating... (with free chapters; also read the various presentations on the site) - http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351 http://www.amazon.com/Software-Estimation-Demystifying-Pract... One key point is to really understand what is risky in terms of estimating (either technically or politically or because it's too vague). At some point, you can really become accurate as long as the scope is well understood. In my case, the Fred Brooks technique does not apply: my last customer iteration was 70% infrastructure, 20% code, 10% pm. The one before was 70% code, 10% infrastructure, 10% documentation, 10% pm.

drbaskin 16y ago

I've heard the following rule about writing (math -- other fields may be different): Take your best estimate, double it, and then increase the units. For example, two days becomes four weeks, one week becomes two months, etc.

dugmartin 16y ago

I always liked the following method: double the estimate and then go to the next larger time unit. So, one hour is two days, 4 days is eight weeks, etc.

frankus 16y ago
Calendar time or billable time? That's probably pretty spot on for converting from the latter to the former (assuming you're honest and don't bill for things like time spent reading HN).

fara 16y ago

Beware of Parkinsons Law: "Work expands so as to fill the time available for its completion."

wilhelm 16y ago

I start with the number of hours it would take me to create something if I was continuously in the flow, motivated and inspired. Then I multiply by π. The results are surprisingly accurate.

rw140 16y ago

Generally I don't get asked for an estimate until after I've done the design, so these numbers are code, unit test and very basic test on real hardware only. These are the rules I use: - If I think I understand everything it involves, then I take my estimate for all the bits, add them up and multiply by 4. - If I think I understand everything it involves, have done something similar before, and gone through my list of things to do a couple of times looking for stuff I've forgotten, I can multiply it by 2 instead. If I'm unsure how long something will take I am never allowed to round down. - If I find myself sizing something with the word 'just' in the sentence, I'm missing something big. (e.g. Then it's just a matter of recreating the error condition and making sure my error gets triggered correctly.) - If I'm not almost finished (i.e. functionality working with some hacks, unit test passes) by halfway through the time then I'm going to miss my deadline. - I am still mystified as to where that other half of the time goes (I have a proper 90% rule going on), but some of it is getting my code in a shape where I'm happy about checking it in - dealing with comments so they mean things to people other than me, removing ugly bits of code, checking with co-workers in places where I wasn't sure I'd made the right decision. My maximum speed on this is about 500 lines a day. Some more time is then spent getting things back working again, because I'll have broken things in the process. And I need at least a day to get a sandbox build behaving properly, and willing to run on my hardware. edit: formatting

robwgibbons 16y ago

Our team can attest to these estimates. Visual layout and design is by and large the most time consuming part of building a website. Code is easy once you know what you're doing.

briandoll 16y ago

How about doing it the other way around? How much value do you think a certain feature is worth? How much time should you spend producing that feature, as relative to its value? Then, figure out a way to ship a viable implementation in that amount of time. There are many techniques for estimating how long software development tasks will take primarily because they all suck. Estimating takes time, and is almost always wrong. Some people even advocate figuring out how off your estimates are, to improve your future estimates, so you can be a better estimator. What? I think it's best to stop estimating and start shipping.

RiderOfGiraffes 16y ago
You're clearly in a different business to mine. Someone comes and asks me how much a feature will cost I'd damn well better be a good estimator, because it's usually a fixed price contract for someone with flow-down penalty clauses. In short, sometimes estimation matters. Knowing when it does and doesn't matter is a different question and a different skill. Perhaps for you it never matters, but before you diss someone as heavily as you just did, I suggest you consider that some people have different circumstances than yours.
- briandoll 16y ago
  There is just so much lost in that phone-tag of a conversation between the actual customer and the actual developer in the scenario I think you're describing. Agile estimating techniques seem to provide a reasonable level of expectation, while placing more importance on collaboration between the product owner and the developers. Once you add development managers, project managers (who are often re-estimating for you, adding or reducing a number to align with some other expectation) and a product owner who's only hearing numbers rather than the details, it's a very lossy conversation. How many estimates have you given where you wish you could have said "but if we just do it like this, it'll only take x% of the time", and how well was that communicated to your client? I just think software estimating as a way of holding a conversation about a product under development is unproductive at best, and often leads to an inferior product .

mrlyc 16y ago

What works for me is to estimate how long a project will take if there are no major problems, then double it.