[peterhunt]

When building the new Facebook photo viewer, we would ship a redesign to a small percentage of users, look at its metrics impact, and ship another redesign 2-3 days later based on the data. Simply being able to execute on something like this for 72 hours, no matter how blindly you do it, is indicative of a worthwhile skill that many people don't have.

[lusr]

That's a great way to iteratively develop a new design (which, BTW, is quite a nice improvement) for an existing product, but what if you didn't have the existing product? How long did it take to build the all the dependencies of the photo viewer?

While engineering the front-end can be done on a 2-3 day turn-around, I'm fairly certain that the engineering problems of storing and retrieving the petabytes of photos that Facebook users upload took far more than 2-3 days. If it used existing infrastructure then you need to count that engineering time in too.

I'm currently 2 months into developing the core technology for my project, working 1-3 hours in the evening after a 10 hour day at my client. Much of this work is with new technologies and mathematics/algorithms I'm unfamiliar with. In this situation, being unable to iterate on a front-end UI design in 2-3 days has nothing to do with skill.

[dominikb]

I disagree. You don't need any skill. Anybody can ship a crappy photo viewer in 72 hours.

But many people can't ship a quality photo viewer even in months.

What heavily distinguished Facebook from Myspace in 2006 when it became open to public was the product culture and quality. It took 3 years to build.

Although I completely understand the point of being able to make quick decisions and execute, the problem is far from solved after spending 72 hours on it. It takes at least weeks to deliver a good solution.

I'm 100% sure you've spent a lot of time with that viewer afterwards until you were confident users will have no problems using it.