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.
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 :)
Currently 1.5 decades in.
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:
1 day = 2 weeks
20 hours = 40 days
1 month = 2 quarters
1 year = 2 decades. =)
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...
If you're a 1:1 consultant, you can probably estimate things a lot easier and that's a good thing.