When I worked at NetApp we had customers in both sides of the world, what we discovered was that the 'enterprise' guys often had a cadence, it went something like grow, identify challenges, coast, upgrade, repeat. That cycle was built around taking the latest release of 'big player' software, qualifying it, then putting it into production, growing a bit, figuring out where the problems were, talking with their vendor, waiting, getting a new release and then repeating the cycle. But the cadence at 'web' players was sporadic at best and often frenetic, feature request, test, iterate, feature, iterate, test, coast, coast, coast, feature, feature, feature, test, coast, Etc. As ideas struck the 'web' infrastructure folks they would would immediately implement some sort of prototype or test case, then rapid fire come up with features the infrastructure needed to support to maximize this feature. But sometimes they would go long periods, months, where nothing would change (in the infrastructure side, web pages, UX, etc sure but same servers and storage assets).
What I learned from that was that while it was great to have some other company own the burden of the 'base infrastructure' in terms of operational expense (hey you don't need Linux hackers if your not changing stuff at that level, so its a savings in staff etc etc) it imposes a hard limit on the change derivative. What happens if you try to change faster than the infrastructure can change, is that you end up hacking around the limits, and that builds up technical scar tissue that over time slows your mobility still further.
So bottom line, you can't continue to pivot faster than your infrastructure, if you're hacking your way around the infrastructure to change, then your ability to change will die by a thousand hacks. If you find your self thinking you need to hack around your infrastructure, listen to that warning and start planning for a more agile base to work from now rather than when we're struggling to keep an old system working while developing a completely new one.
There is a balance that one has to achieve between agility and stability - but that balance, the agility and stability can all be compromised based on early infrastructure choices.
Sadly, early infrastructure choices are 99% of the time predicated on available budget.
Due to this, there is one infrastructure choice, policy really, that can be made that will provide you with the best available path throughout the life of your companies infrastructure: VIRTUALIZE EVERYTHING
I spend a lot of time in the weeds of infrastructure as I design the physical cable-plant and data center environments that people shove all their stuff into - I cannot virtualize physical cables - but I design the plants around the idea of virtualization.
This means that you want to collapse your traffic to as fat a pipe as possible as quickly as possible. Allowing you to run minimal physical cabling.
as you grow as a company, and you get to a point where your services will transfer from hosted infrastructure to owned infrastructure maintain as much virtualization as possible which will allow you to pivot easier higher in the stack.
With virtualized storage now, the only thing you cant virtualize is your actual transit.
It's funny how net diags now just look like a bunch of tiny clouds linked together then simply to larger clouds.
That seems ridiculous to me.
The being in L.A. thing might be less ridiculous, but I also find it hard to believe that there aren't boatloads of developers in L.A. who couldn't add value to a social networking site.
The reasons that come to mind for why Facebook initially started to attract users away from Myspace are that its profile pages didn't look like the Trapper-Keeper of a 14 year old, and the fact that it had exclusivity from being associated with Universities.
edit(I forgot this one as well): Also the shift from having to seek out your friend's pages to having their updates show up on your main page seemed like a big differentiator.
You can chalk the enhancements made to Facebook after that point to their underlying technology, but I really don't think ASP.NET was responsible for why Myspace sucked.
That said, I think he could have better put it by saying he thought MySpace needed rock star developers, and that they had a harder time getting rock star .NET devs. I'm still not sure that's actually true, but at least it's a little more reasonable.
Anyway, I'm pretty sure Facebook was already eating MySpace's lunch before they even made the asp.net switch. Maybe not in pure numbers, but definitely in momentum.
Edit: Not that I think MySpace needed rock star developers, just my take of what Scoble was trying to say.
They could have matched Facebook feature to feature and that too the very next moment. I can guarantee that it would not have changed a thing. Google came out with numerous social plays with better strategy, scale and speed without much success.
Finally if Myspace could not change fast enough it cannot be attributed to the platform. In hindi we have a saying, "naach na jaane aangan tedha"(calling the floor crooked, when you don't know how to dance).
Silicon Valley might be awesome for its talent, but I would bet that there are enough awesome developers in any metropolis to make any web company successful. You need to be a place which needs to be able to attract such people. Being in SV would not have changed a thing, as no good person would have wanted to join Myspace.
At any rate, you can still make it work. Google has an office with developers in Santa Monica (west LA). And StackExchange is a great example of making the MSFT stack work.
By the way, any MySpacers here that got laid off or looking to jump ship?
I'm a developer at Leads360 in El Segundo, CA. And we're hiring developers right now! I've interviewed several MySpacers already and extended offers to a few. We hope to get more :)
Send me your resume, if interested. Good luck.
Bill Paetzke: email@example.com
Even if close to true, it would be their specific architecture, not the stack.
Sounded like a mess and other developers in audience felt the same way. Then I signed up and saw how bad it really was as half my searches resulted in errors and the design sucked, among various other issues. Facebook was just awesome in comparison. I think MySpace's death spiral can be almost completely attributed to their lack of professionalism, for lack of a better word, from the start and the only way to remedy would have been to start from scratch.
I have a bunch of friends from MySpace and one common theme I do hear is that they feel that a better architecture (not connected to the stack) would have let them ship stuff quicker.
The interesting thing here from Nick Kwiatkowski's comment on that page is MySpace did a lot of things you'd often see on advice posts here - like "Rearchitecting/rewriting from the ground up is almost always a fool's errand". It seems like there is a limit to technical debt you can endure. If you rewrite too quickly, you'll be made fun of as the company which killed their product by trying for a massive rewrite/re-engineering effort. Take too long and somebody like FB gets to ship features very quickly and leap ahead of you.
What on earth does this mean? I thought the ashton kutcher meme was simply down to his meteoric popularity on twitter, but this implies that there is something startup-specific about it.
I don't know who his tech handler may be (if any) but they get him exposed to some very interesting projects, and I think that he has made some great choices on his investments. Further, his lending of some of his celebrity to (twitter and otherwise) is a good thing for those that he invests in.
I can say, that if I were in his shoes, I would be doing exactly what he has done -- take the money made in his industry and invest heavily in tech.
In fact, based on his broad range of exposure alone, I would be very interested in his opinion as an angel investor in my projects as I do think he has a pulse on contemporary tech and how well it could be adopted.
Whether that is due to his own acumen, or that of some staff of tech advisory (or just friends) that introduce and connect him to deals is unknown.