Hacker News new | past | comments | ask | show | jobs | submit login

When I was hired as a consultant, the very first day I was asked to give an estimate on how long it will take me to complete the project. (Coincidentally, it was for a New York Times)

I spent my time studying the code base and the requirement. By the end of the day, I told them around ~20 hours. It was a fairly easy project.

I spent a month and a half to complete the project. What I didn't take into account was how long it will take to get resources from them. When I asked a question, it took anywhere from 48 hours to an entire week to get a response. When I completed a task, I got no response.

But I needed to be on call because they would sent hundreds of emails about everything except what was needed. I charged them for all the hours I spent waiting for them, and reading long emails that led nowhere.

My rule of thumb (can't recall where I first heard of this, but it's not original) for translating from an engineer "how long will it take me to create a technical solution" estimate into the real world is to convert the estimate into the largest whole-number unit (so ~20 hours would be 3 days), then double the scalar and increment the unit, in this case 3 days would become 6 weeks - which while not perfect, is much closer to the reality than your original estimate.

I'm amazed by how often this rule has turned out to be reasonably accurate, though I'm sure there's some selection bias at work. And it certainly starts breaking down when you begin estimating in multiple months - however I would counter that if you're able to credibly estimate months of work on a solution, then you don't need this particular rule of thumb :)

Berlin Brandenburg Airport was originally supposed to take 5 years, so according to this it will take 10 decades.

Currently 1.5 decades in.

IF they're smart, they'll just change the estimate to 5 more months and get it done in 10 years.

Yes, this is what has been defined as "Latin" Time, JFYI:


and it doesn't affect only software projects.

Shouldn't apply - in theory - to Germans, but as the following post suggests about the Brandenburg airport, it may.

Empirically this rule of thumb tends to be more accurate that the better known ninety-ninety rule:


The old rule of thumb is "take the estimate, double the number, and increase the units by one."

1 day = 2 weeks

20 hours = 40 days

1 month = 2 quarters

1 year = 2 decades. =)

These rules of thumb are humorous, but they indicate an appalling lack of ability to both estimate and manage a project.

I've been a self-employed software engineer for more than a decade and I've worked on 100+ projects. Very few of them got done on the original timeline, but none of them were overdue to anything close to this degree.

If I tell a client it'll take 3 weeks and it takes 6 months, there will be a mountain of shit raining down on me (and them), starting with them never working with me again, and possibly ending with them refusing to pay at all or legal action.

Not to mention that you'll never win the project in the first place if you start quoting your estimates this way: "Hmm, that $4,000 site that I think will take 20 hours at $200 / hr to build? I'll just quote it at $64,000 to be on the safe side."

(Note: just an example, you shouldn't price projects this way anyway)

These naive rules of thumb are always so arbitrary too. Why bother with the doubling and changing of units, just multiply by 1000 and call it a day.

A much better rule of thumb is 1.5x to 3x, depending on how conservative and experienced you are, how many risk factors the project has, how much you'll be depending on the client, etc.

Software is really hard to estimate properly, and cost and timeline overruns are a fact of life. But if you regularly find yourself 10x overdue, you should probably revisit the way you're doing this.

Major IT projects are almost double over on timeline on average, but not 8-10x: https://www.economist.com/business/2005/06/09/overdue-and-ov...

I agree, they're humorous, but looking back at the larger scale projects I've done over my career in larger companies, the results have always slid into the double/double category more times than I'd like to remember.

If you're a 1:1 consultant, you can probably estimate things a lot easier and that's a good thing.

Do you have any resources about good estimation? I have good intuition how to approach it and generally I'm close to estimated values but I'd like improve still.

Even after 18 years it's still a bit magic to me. The only thing I can pretty accuretely tell is... if I can estimate it correctly. So if I say "1 day" it will be 4h-16h, when I say 3 days, it will probably be done in a week. But if say "I have no clue" - then it can literally be 1 day to 1 month.

it might have still ended up as 20 hours of your time doing the actual 'work', but all the ceremony and support around everything else if 5-10x what you think it will be.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact