Take your estimate. Double the number. Then go to the next unit.
So if you think you can do it in 2 weekends, 2x2 = 4, and the next higher unit is weeks. Sounds like a four week job.
The beauty of this is that it doesn't rest in any mathematical principles at all -- it's totally made up. Just like regular project estimating.
Double it, add another unit up. So, two days becomes four days + 1 week = 11 days. I've found this (depressingly) accurate over a large sample size.
The only problem is, for each new task, I refuse to accept that such a "ridiculous" estimation could be correct, so I just stick with the original.
And the cycle continues...
Then after a few months you should have a good set to look at and hopefully convince yourself to believe your modified estimates. Or how to adjust your formula to be more accurate.
Really the point is to keep yourself honest and realize that things tend to take a lot longer than you'd expect.
Also, if you are scoping a project out in terms of years you probably want to break it down into smaller features and implement them one-by-one.
I'm writing a book on the method -- as soon as I figure out how to stretch one sentence into 400 pages.
Of course it has a few bugs: It isn't really polished, is easy to game, vulnerable to attacks, a security hazard, doesn't work in IE6, isn't scalable, dosen't verify links properly, sometimes misses dupes, doesn't have a proper admin interface and needs some design love.
But except for that, and a few other things I can do in a weekend it's done.
:-)
The "I can do it in a weekend" meme is just ruthless application of the 80/20 principle. Pick out the most useful 80% that'll take the shortest amount of time to implement. Then repeat until you've got the time down to a weekend. Chances are that if you've picked well, you've still got something fairly useful. Most decent software ideas have a useful kernel that really can be done in a weekend.
Gall's Law: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Once you've got folks using your system, then you can worry about all the nitty-gritty details. But generally, it doesn't matter.
That's why the "weekend" meme persists. It's not about being "done" (software is never "done" anyway), it's about getting it to a point where "done" has meaning.
The little stuff can always be done. But my fear is that the people who insist on mocking the weekend hackers are the people who refuse to start on the big thing for fear that they'll take too long.
Regarding a HN clone:
Sorting? Just do it by date. Logins? Just a basic login, perhaps with tons of security vulnerabilities. Flagging? Later Comments? Not yet.
Once you have that, which is usually just a weekend job, then you can start to see what's going to be necessary and what isn't and start to see some of the edge cases and features you didn't even know you would need.
Actually it occurs to me it would be incredibly interesting to see someone's attempt at cloning justin.tv in a weekend. Sure it's impossible, but I would be fascinated to see what got done if someone actually tried.
As long as you're the one working for them and not me.
I'm still revising the text and doing some other things. I'm going to start promoting it soon. Please join if you're interested.
However, I think all of us at some time or another worked up the courage to build something much larger, important, or interesting because we deluded ourselves into the belief that it would be simple or easy or only take a small amount of time.
I consider this nearly universal estimation problem a benefit to the entrepreneur (at least at the beginning). It allows people to start projects that would be too daunting if they saw each and every task in front of them and that it would actually take them many months or years of their lives to make it work.
Unless you have delivered systems in 2 days, you probably don't have a process that supports delivering systems in 2 days. That's why delivering something in 2 days is a good thing to try. I like this post of a team building something in 4 hours. http://blog.palantirtech.com/2009/07/06/the-multisnake-chall...
