

The Mythical Man Weekend - kolya3
http://blog.clickdeck360.com/the-mythical-man-weekend
Deconstructing the "I can do it in a weekend" fallacy, feature by feature.
======
mixmax
I actually built a HN clone in a weekend.

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.

:-)

~~~
DanielBMarkham
Heck, I could do it in a day -- as long as I get to define done!

~~~
wooby
Sometimes even when I define what done means before I start a project, I
embarrass myself with my underestimates of complexity. Software is just plain
fickle. Proof of concept on most any web app? Weekend. Something that
satisfies anyone but me? At least two weekends :)

~~~
Periodic
Your first mistake was thinking "done" has a fixed definition.

------
abstractbill
The world needs _more_ people saying foolhardy things like "I could do that in
a weekend", not less.

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.

~~~
mattchew
_The world needs more people saying foolhardy things like "I could do that in
a weekend", not less._

As long as you're the one working for them and not me.

------
mgenzel
While his specific point is true, it is also true that delusion can be a
valuable tool of progress (aka if we knew what having children is really like,
the humankind may have died out). Obviously, you can't hash out a full-fledged
system in a weekend, but you can get enough of a start that it pulls you in
and makes you work on it after the weekend is done. Also, sometimes you can
actually build a pretty sophisticated project if you have done enough of the
pieces in the past. Of course, all of the above applies only to self-inflicted
work; "managerial pressure" should be resisted :)

------
wyday
He has a point, but anyone who has ever built something non-trivial from start
to finish already knows this. It's the subtleties, not the broad concept, that
drains time.

~~~
ajross
But it's the _concrete_ knowledge that your prototype just needs polish that
makes the "weekend hack" valuable. Given the choice between two developers
with proposals, one of whom spent last weekend banging out a prototype but
with no plan, and the other with an elaborate plan and documentation but no
code, which would you pick?

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.

~~~
Periodic
Spikes (in the agile nomenclature) are great fun. You just try to figure out
what the shortest point from where you are to minimal functionality is, then
get there.

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.

------
kneath
This post feels a lot like he reworded
[http://blog.bitquabit.com/2009/07/01/one-which-i-call-out-
ha...](http://blog.bitquabit.com/2009/07/01/one-which-i-call-out-hacker-news/)
but with less insight & effort and inserted a couple drawings instead.

~~~
cdr
To me, it gets the same point across more simply, clearly, and quickly.

~~~
ErrantX
indeed the original post felt a bit ranty

------
steveeq1
Guys, I'm setting up a meetup for hackers that does this exact thing. It's
right here: <http://www.meetup.com/lets-build-something-together/> . Think of
it as speed dating for hacker.

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.

------
DanielBMarkham
Here's Daniel Markham's surefire rule to estimate projects:

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.

~~~
mixmax
I have a project I think I'll be able to do in a year, what unit should I use?

~~~
DanielBMarkham
Sounds like a two-decade job, my friend.

I'm writing a book on the method -- as soon as I figure out how to stretch one
sentence into 400 pages.

~~~
mixmax
I know a management consultant that has a surefire method of stretching a
sentence into a book. He is also good at stretching the truth. I believe he
helped Tim Ferris out with _the four hour workweek_

~~~
req2
Are you saying the book should be called the eight day workmonth?

~~~
DanielBMarkham
Sounds like a cool book. I'll have to read it after I finish the 2-hour
manager.

------
edw519
I've been 90% done for years.

~~~
samlittlewood
Heh! - easy - just the other 90% left.

------
wglb
Great headline, and I cannot enumerate the number of times that I have done
this, both under managerial pressure and totally of my own volition.

------
jeremymims
I understand the annoyance at someone saying they could replicate a product in
a weekend. And I also understand the desire to say that this is a bad idea
because it probably isn't possible.

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.

------
mattmcknight
I think a useful place to begin estimates, before you dive into the detail
level and go bottom up from tasks, is estimate by analogy. Look at how long it
has actually taken you or your team to deliver a real system. Use that as the
baseline for the estimation process.

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...](http://blog.palantirtech.com/2009/07/06/the-multisnake-challenge/)

