There's a great Mixergy interview about how Digg wasn't built in a day either. Owen Byrne, the guy who built the original Digg site, talks about how much work it really took.
http://mixergy.com/pr-lies-destroy-your-understanding-of-how...
There's a great Mixergy interview about how Digg wasn't built in a day either. Owen Byrne, the guy who built the original Digg site, talks about how much work it really took.
http://mixergy.com/pr-lies-destroy-your-understanding-of-how...
And when it comes the time to do it, the core functionality can be done really fast if you have good tools, since you are prepared for it.
What separates the good projects from the bad ones though are final touches and the features that are expected by the users - those weird business logic additions that aren't properly defined. These take an incredibly long time to do. Not to mention deployment and scaling which is always a fun ride.
And of course, there's always that intern/junior that has to work on something, and he's given the task of helping you, leaving a mess in any module he touches ... and then you have to clean-up the code, just to keep your sanity.
You have to think about things such as adding a new feature which works well with the rest of the site, add the new code without making a mess, change the existing implementation of a feature 'cause you realize your first implementation was not the best way to do it, or that it does not work so well with the new feature etc.
All this time and effort should be counted in - putting out an initial release is good, but you still have a lot of work left to do.
Show this, hide that. Click this, open with ... a fade. ABC
It's the business rules that each line of code is trying to accommodate that takes the longest to work out. Thinking out the ripple effects on the future is the time killer.