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.
That's exactly the point though. You're never done with a software project, so define "done" in a way that gives you something maximally useful in a minimum amount of time.
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.
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 :)
The best time to define done is when the time period has expired. Just take what you've done, list that as your acceptance criteria, and viola! You're batting 100%.
Comments
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.
:-)
Heck, I could do it in a day -- as long as I get to define done!
That's exactly the point though. You're never done with a software project, so define "done" in a way that gives you something maximally useful in a minimum amount of time.
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.
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 :)
Your first mistake was thinking "done" has a fixed definition.
Yes. I agree.
The best time to define done is when the time period has expired. Just take what you've done, list that as your acceptance criteria, and viola! You're batting 100%.
(And yes, I did that on purpose)
I too did something like HN on a lazy weekend