Tell HN: My rule of thumb for initial estimation | Hacker News Reader

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

View on HN

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.

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

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.

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.

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

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

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.

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.

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

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

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.

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.

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 .

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?

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!

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?

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.

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.

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

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.

Reply on news.ycombinator.com