Tell HN: My rule of thumb for initial estimation

[RiderOfGiraffes]

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 ...

[dugmartin]

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]

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).

[cperciva]

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]

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.

[rw140]

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

[drbaskin]

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.

[thibaut_barrere]

I don't multiply by 6, instead I use various techniques that works quite well:

- 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-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.

[gte910h]

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).

[fara]

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

[briandoll]

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]

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.

[HeyLaughingBoy]

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?

[grigy]

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

[wilhelm]

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.

[mrlyc]

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

[robwgibbons]

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.