

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

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

------
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...](http://www.mountaingoatsoftware.com/books/1-agile-estimating-
and-planning) (with free chapters; also read the various presentations on the
site)

\- [http://www.amazon.com/Software-Estimation-Demystifying-
Pract...](http://www.amazon.com/Software-Estimation-Demystifying-Practices-
Microsoft/dp/0735605351)

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.

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

~~~
RiderOfGiraffes
I'm sorry, but that meant absolutely nothing to me.

Your final line was:

    
    
      > I think it's best to stop estimating and start shipping.
    

My point is that when I need a broad plan of what to implement, how much scope
to include, when something will be ready by, and how many people will be
required, I need to estimate. Sometimes I need to do that before I get down to
the nitty-gritty of the real design, real implementation and real details, so
I need some rule of thumb to let me give broad ROM estimates.

One of our major customers recently asked for a feature and my sales colleague
asked how long it would take. We didn't really know what the customer thought
they wanted, so I went into a huddle with my lead programmer and together we
sketched a reasonable feature that seemed to match the requirement, and
estimated about 4 days of actual coding. I went back and replied that it would
be 5 weeks of work on this feature (4 x 6 days) and that, given other
commitments, that would be about 3 months elapsed time (one programmer working
1/2 time). So that's 5 weeks NRE on this feature, 3 months to delivery.

The feature was priced accordingly, and when the customer upped the priority
we put a programmer on it full time. It was delivered to site and signed off 6
weeeks later.

Sometimes you need to estimate.

So, what was your point?

ADDED IN EDIT: I am, by the way, quite serious about that question. For me, in
my circumstances, I really, _really_ need to estimate in broad outline and get
it roughly right. I'd like to see a clear exposition of why you think what I
do is wrong. Could you perhaps write a more considered piece on your blog and
link to it?

~~~
briandoll
I agree that this is a very good topic and I'll flesh out some thoughts and
post them soon. I'll email you when it's up. Would love to continue the
dialog!

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

