Did the Microsoft Stack Kill MySpace?

".Net programmers are largely Enterprise programmers whom are not constitutionally constructed to create large scalable websites at a startup pace."

This is such BS, I can't even read it without physically cringing. I work for a ~400-person business that stands up .NET websites at breakneck speed, and we do it well. People who blame their problems on technical infrastructure decisions almost ALWAYS do so because it's easier than addressing the true underlying problems.

"The biggest problem was they didn't allow the developers to have staging or testing servers -- they deployed on the production servers on the first go-around... And all this with no change management or control. No versioning either."

Oh wow. Wow. I hereby revoke my previous statement. These are some God-awful infrastructure decisions. Version control and a staging server are the most basic necessities for a scalable dev project. I even set them up when I'm working on a personal project, alone.

I worked at MySpace on the MDP ( MySpace Developer Platform ) team. My team, MySpaceID, was the one that implemented Oauth 1, 2, 2.0a and all of the external REST libraries. We worked closely with the activity streams team and the OpenSocial Team. We also launched the MySpace JSL or MySpace Connect. We were the 1st to do a popup login flow for OpenID and several other cool things MySpace was doing to catch Facebook. We might have done it if Google did not pull the money.

Once the free parking was pulled from MySpace, 50% of every team was laid off and all of the momentum was pulled from the company.

Working with .Net was not an issue, and in some cases it was a benefit.

There were however huge cultural problems with FOX. Here are a few.

Developers used were given one display, not two. Screens were 1280x1024. I bought my own displays and had my manager order a custom computer for me with dual video card support.

Fox was a closed source company, and so when we were working on Open Tech like Oauth and OpenSocial gadget servers, we had to do it as closed source software. We had no peer review. It made it really hard to ship and test something when you don't have linkedin, google, bebo, and twitter reviewing your code. On top of that when those companies found a bug, we had to re-implement that code in .Net. On top of that MySpace and .Net were well designed for strong typing and those types work a bit different than Java.

It didn't take a lot of time to port so, we kept doing it, but you have to think about this, you are at a race with a company like Facebook who had zero profit motive at the time, and billion in funding and a ground up stack. Meanwhile MySpace was just clearing out cold-fusion and we had really old blogging platforms that could not just get ripped out.

We also had management that didn't want to piss off users and so we would have 2 or 3 versions of the site out there, and we required users to upgrade to new versions.

What MySpace had was Cultural Debt, and a fear of destroying what they had. Facebook won because they were Socratic to the core.

No, Facebook did. And they did it with crusty old PHP which pretty much proves the platform isn't going to make or break your business.

Finding good talent that's experienced with huge scale sites is not going to be easy regardless of language. It's not like MySpace could have been RoR and suddenly everything would have been simple, at their prime they were doing a ridiculous amount of traffic that only a handful of sites ever had experienced. There were probably 0 people experienced with PHP at Facebook's level, they all had to learn as they go and what they learned was they picked the wrong language so they created HipHop, a hack to overcome PHP and probably hundreds of others that help them scale better.

Its funny I don't know (can't think of one) of a high traffic site that "died" due to technical failures (particularly scaling failures). Twitter had massive problems during its growth phase, Reddit has had similar problems. Does anyone have an example of a site that got "killed" by technical issues? I'm really curious.

Bad products tend to die or get replaced by superior offerings. Thats the nature of business.

Not being able to innovate rapidly because of technical lock in is the only way these types of issues can "kill" a site. But its very hard to quantify these types of issues. Between this article and Kevin Rose's statements about hiring B&C level programming talent it seems like a lot of engineers are getting tossed under buses, for poor management decisions.

MySpace wasn't always .NET. It was ColdFusion before .NET v2 came out. Not that ColdFusion would have made any difference.

That said, I'd argue that no, Microsoft did not kill MySpace. Generalizations like this are wrong. There are many more .NET enterprise developers out there then there are Ruby or Node or Python. With quantity comes a varying degree of ability. MySpace killed themselves by lowering their standards to the easy-to-find .NET developer instead of setting the bar higher. Once you lower the standard by which you hire developers, it's a cycle. The new guys will lower the standard a little more to hire the next set, etc.

The lesson to be learned here is if you can't find a good developer, don't blame the technology stack you've selected, blame your recruiter. Find the person you want, they are out there.

Scoble's thesis seems way off. The problem with MySpace wasn't the technology, or even the site. It was the users of the site. It became a place that people didn't want to be associated with, while Facebook became that place. If MySpace instantly could flip a switch and turn into Facebook (codewise) hardly anything would have changed.

MySpace's problem IMO wasn't technical at all. They built a service that focused on users most likely to move, and repelled those most likely to stick with a platform.

Platform fetishism[1] and attempts to throw developers under the bus[2] aside, the comment from Nick Kwiatkowski states a much better reason: developers weren't empowered do their jobs.

The comments state that there was no staging or test environment, no ability to roll back releases, refactoring was a dirty word (engineers wanted to refactor, but couldn't), principal on technical debt was never paid (only the interest in terms of hacks to make the site scale-- again, product organization prioritized new features).

The rest: location, technology choice aren't sufficient to "kill" a company: there are successful companies in LA, there are successful and agile companies using Microsoft stack (where appropriate-- see Loopt and StackOverflow/FogCreek as examples of companies using both FOSS and .NET). On the other hand, they're not optimal either: they aren't what engineers would choose themselves most of the time.

This indicates that the technology and location choice aren't the cause, they're symptoms of company management that doesn't understand building non-trivial Internet applications (what the optimal technology stack for one is; where, when and how to hire developers to build one) and yet maintains authority to make all technical decisions. Contrast this with Facebook, Google et al-- where every process (from corporate IT to production operations to HR and recruiting) is designed with needs of the engineering organization in mind: "Want two 24" monitors? No problem. Want Linux on your laptop? No problem. Want ssh access to production? No problem. Want to fly in a candidate to interview? No problem."

[1] I personally wouldn't touch Windows with a sixty foot pole, but speaking objectively C# >3.0 and (especially) F# are great languages.

[2] "They weren't talented": having interacted with some ex-MySpace engineers, this just isn't -- at least universally -- true. Indeed, here's a secret to hiring in an early (Facebook in 2005) startup: seek out great developers who work for crappy companies, people who have joined "safe bet, resume brand" companies like (post ~2003) Google aren't likely to join you until you've already become a "safe bet, resume brand" company (Facebook in 2008-Present).

If a headline ends with a ?, the answer is generally "No."

I worked at MySpace, specifically the middle tier where these technical issues supposedly existed (scalability), although I also worked on a number of user and non-user facing projects during my time there. You may consider me biased because of that, but I'd say I also have a pretty good view into the issue. The reason for MySpace's downfall is crystal clear to anyone who worked at the company and cared to look around and make sense of what was happening - it was catastrophic lack of leadership and vision in management and product, paralyzing political infighting, and general lack of competence at the top levels of the company's management. The people making the decisions would change their mind and requirements constantly because of this. There were numerous entire features that were simply not launched and abandoned AFTER they were completed because the management couldn't agree on how they wanted to "position them" (and they were great features). The top management level was in a constant state of political infighting, and that most likely came from fox and the way they ran shit. There was no one to judge and reward competence at that level, it was simply about who could cover their ass better or come out looking better. MySpace was huge, and everyone just wanted a piece of the pie.

One of the issues that stemmed from this was lack of respect for technology in the sense that no one at the higher levels saw the company as a technology company. They saw it as an entertainment or media company. That created the cultural problems on down that eventually contributed to bad products and shoddy implementation.

Now, the core technical part of the organization was actually extremely competent. MySpace was pushing more traffic than Google at one point in its heyday, and the site scaled just fine then. That wasn't an accident, I have worked with some of the smartest people in the industry there. But because tech wasn't the point for executives, those people were tightly controlled by non-technical management, and so products suffered.

MySpace could (and still can) scale anything, to say that they had a scaling problems by the time they got to their peak is complete gibberish. Over the years they have developed a very mature technology stack. No one knows about it because it's entirely proprietary. The problem was management and product that was basically... incompetent, and lacked anyone at the proper levels who would care to see and fix it.

EDIT: Some typos and missed words. I'm sure still missed some.

Am I the only who thinks a large reason why MySpace lost to Facebook was design?

MySpace just gave way to much flexibility to the users to modify the look and feel of their pages that it just got way to busy and very difficult to look at.

In some respects I think it was MySpace's business proposition to allow users to create their own personal spaces on the web easily, whereas, Facebook's goal was more to connect you to your friends. In that sense MySpace followed through, although that follow through seemed to lead to their demise!

Holy mother of god, no change management, staging or testing servers? On a site that big?

Appalling, if true. (Not that good technology and process would have made the product suck much less.)

Having read the article, as well as Scoble article linked I would have to disagree that it was the Microsoft stack. There was just not enough investment in their programmers. I work at a small startup where money is rather tight while we raise funding and attempt to get contracts in, yet us developers get what we need. Every developer has at least two screens (be it a laptop and a large LCD, or a desktop with two the same monitors). We can ask for new staging servers, we can ask for more memory, we can set up our own infrastructure, and we can make technical decisions.

Once you start taking away the ability of devs to think for themselves or feel comfortable doing work it makes it harder to be motivated to come into work and fix the issues, and if management isn't listening to the complaints about the need to re-factor then what is the point? Adding hack onto hack gets boring pretty damn fast.

MySpace also lost in that they really didn't have a direction of where they were going (at least that is what it looks like looking in). Blogs, music, status updates, what was it supposed to be? And it didn't help that all over their web properties they didn't have a consistent look and feel because they allowed everyone and their mother to skin their profile page how they saw fit leaving it a disjointed mess that just made me hate the site more.

(former MySpace and former .NET team @MSFT) Let's just say the Microsoft stack probably didn't kill the beast… ASP.NET certainly didn't help though.

It's too bad that all the tech built around .NET will be lost to the annals of MySpace, MSFT should acquire the company just to open source the whole thing for the benefit of .NET.

Regardless, it's fair to say starting a company on "the Microsoft Stack" today would reflect questionable judgement. Are there any recent ex-MSFT founders on it?

The technology never kills the business; it's ALWAYS the people. However, I think this points out the extreme importance of getting good people who make good technology choices.

MSFT products are not inherently evil; they have some advantages for some types of projects. But a proprietary closed source stack always puts you at a disadvantage.

Worst case scenario with open source, you go patch what's holding you back in the open source. With bugs in MSFT products, you are at the mercy of MSFT to prioritize your issue. If you are a big enough fish, then they will pay attention. Otherwise, good luck.

I don't understand why anyone would willingly tie themselves to the Microsoft web dev stack as a startup. Even if you don't have to pay upfront, you will pay dearly in the future when you go to scale. At one startup I worked for we were hamstrung by not being able to afford the upgrade to Enterprise SQL Server, for example. So our data replication was tedious, time consuming and prone to failure.

In my opinion, some of it also had to do with inconsistent and ugly hacky Myspace user experience.

White / Yellow / Green / Red fonts on black backgrounds with animated gifs + glitter and broken plugins will be the response to the question "What comes to your mind when you think of Myspace UI experience?"

In comparison, the facebook experience was a lot more fresh, clean and unified.

Twitter had scalability problems and they were on RoR, but it got solved. Scaling to those levels is always going to uncover problems in your architecture. What mattered was the way MySpace chose to execute, not the technology they did it with.

Scalability is relatively new hiccup; given the fact that only in past few years users have swarmed the internet. Sites never expected that and developers weren't prepared. They learned mostly by trail and error and reading case studies and then figured out what to do. You would find inexperienced PHP devs who don't know scaling just like you would find .Net devs.

I think the article has the right notions. Stack doesn't matter, a team of highly motivated devs who can milk the technology involved is more important.

As someone who was fairly intimately involved in the entire evolution of the MySpace stack, I'm dumbfounded at the number of inaccuracies in this article (actually, it's hard to call them inaccuracies so much as an exercise in "I'm going to write an article based on some stuff I heard from disgruntled people."). I developed in non-Microsoft technologies before and after MySpace, and I can tell you that, like all technologies, the Microsoft web stack has strengths and weaknesses. Performance was a strength, non-terseness of the code was a weakness. Modularity was a strength. Etc. Have any of you encountered a technology where, as much as you like it, you can't rattle off a bunch of problems and things that could be done better?

The web tier has very little to do with scalability (don't get me wrong, it has a lot to do with cost, just not scalability, except in subtler ways like database connection pooling)--it's all about the data. When MySpace hit its exponential growth curve, there were few solutions, OSS or non OSS for scaling a Web 2.0 stype company (heavy reads, heavy writes, large amount of hot data exceeding memory of commodity caching hardware, which was 32 bit at the time, with extraordinarily expensive memory). No hadoop, no redis, memcached was just getting released and had extant issues. It's funny because today people ask me, "Why didn't you use, Technology X?" and I answer, "Well, it hadn't been conceived of then :)".

At the time, the only places that had grown to that scale were places like Yahoo, Google, EBay, Amazon, etc., and because they were on proprietary stacks, we read as many white papers as we could and went to as many get-togethers as we could to glean information. In the end, we wrote a distributed data tier, messaging system, etc. that handled a huge amount of load across multiple data centers. We partitioned the databases and wrote an etl tier to ship data from point A to point B and target the indices to the required workload. All of this was done under a massive load of hundreds of thousands of hits per second, most of which required access to many-to-many data structures. Many startups we worked with, Silicon Valley or not Silicon Valley, could not imagine scaling their stuff to that load--many vendors of data systems required many patches to their stuff before we could use it (if at all).

Times have changed--imagining scaling to MySpace's initial load is much easier now (almost pat). Key partitioned database tier, distributed asynchronous queues, big 64-bit servers for chat session, etc. But then you factor in that the system never goes offline--you need constant 24 hour access. When the whole system goes down, you lose a huge amount of money, as your database cache is gone, your middle tier cache is gone, etc. That's where the operations story comes in, wherein I could devote another bunch of paragraphs to the systems for monitoring, debugging, and imaging servers.

Of course there's the data story and the web code story. MySpace was an extraordinarily difficult platform to evolve on the web side. Part of that was a fragmentation of the user experience across the site, and a huge part of that was user-provided HTML. It was very difficult to do things without breaking peoples' experiences in subtle or not subtle ways. A lot of profile themes had images layed on top of images, with CSS that read, "table table table table...". Try changing the experience when you had to deal with millions of html variations. In that respect, we dug our own grave when it came to flexibility :).

Don't get me wrong, there were more flaws to the system than I can count. There was always something to do. But as someone who enjoys spending time on the Microsoft and OSS stacks, I can tell you it wasn't MS tech that was the problem, nor was it a lack of engineering talent. I am amazed and humbled at the quality of the people I worked next to to build out those systems.

If the MS stack killed MySpace, then PHP made Facebook?

I'm not sure these technology-based analyses are correct. I had four teenagers at the time and they all switched from MySpace to Facebook because the MySpace pages got cluttered with glaring ads. The Facebook layout was cleaner and had no ads (at the time). There was no problem with site speed.

I may be incinerated for saying this, but maybe stupid decisions are a symptom of the incompetence that doomed MySpace to failure.

Let the big karma fire begin.

edit: somewhere else someone mentioned they used Cold Fusion. I consider that another stupid decision. But at least they were migrating out of it.

It's nice, in a sense, to allow people to out themselves as mistaking technology for culture. You can write slow code, and make bad choices, on any platform.

My colleagues at Stack Overflow work faster and produce more -- at obsessively fast web scale -- than any team I have observed. I also see talented people struggle to produce a viable site using (say) Ruby on Rails.

Technology correlation? None. The correlation is in discipline, understanding the tools, foresight, priorities, management...

Think of it this way...how often have you seen a headline on HN bring a site to its knees? Fair guess that many of them are on "scalable" technologies.

For me the UX killed it. Allowing any user to design their myspace page was a bad decision. It was so annoying to find the information that is most important in a social network on many of my friends and general user's pages, as many just add crap on top of crap. Also, the terrible opening a MySpace page and immediately hearing a song or piece of music and madly scrolling down the page to find where to stop the awful sound. Most of the time I would just close the window in disgust.

The theme of the other comments on this thread seem to be ".NET? newbs!" or "Facebook worked even though they used PHP!". Keep in mind that at the time MySpace and Facebook were created, .NET was by far the best option out there for a scalable framework, they converted their Cold Fusion infrastructure over to it. It also may be hard for the Rails kids to believe, but PHP was the Rails of that time.

I think it's simple. If you're business requires scaling at this level you need to have really good engineers and they need to have a lot of say in how things are done. I've worked with a number of "product" people from myspace, and they were definitely not doing 1 of these two, maybe both.

No, Myspace failed because it was a shithole filled with awful people that nobody took seriously, and Facebook turned out to be relatively clean and useful.

Don't blame technology for your failings. Facebook won because it had a first name and second name field.

Give me a break!!! Teenagers with animated gifs, a horrible taste for colors and true angst along with Rupert Murdoch's old school leadership killed myspace. Before you blame the stack, look at the content and lack of a proper newsfeed. Ugh

Facebook hasn't always been a good performing site. I remember up until recently if you clicked on the "Info" tab on a person's page you'd get a loading gif for 10-15 seconds.

Hearing a blogger that has no idea what he's talking about make such generalizations as 1) There are no good c# developers and 2) There are no good developers outside the bay area shouldn't bother me but it does.

I really doubt the MS stack had anything to do with it. I think it's more of case of a combination of a different online social shift (from scrapbooking to social circle behavior tracking) and resting on your laurels (e.g. refusing to evolve before Facebook became dominant).

In their defence, what Facebook stumbled upon was really simple and yet very non-obvious (at least initially).

Myspace was killed by backwards compatibility.

One key aspect of Myspace is how customizable it is. As any programmer can tell you, this limits the ways features can be rolled out.

For example, you want to have a new layout? Too bad. It will break the users customization.

You want to add a new button? Too bad. There is not a coherent place where you can add it.

You want ajax? How will that break users layouts?

Stackoverflow doesn't seem to have many problems with it. Anyone who has done any C# programming knows .Net is * embarrassingly fast* these days. It'll save you a lot of "scaling" money.

What killed MySpace is poor management. It is one of those companies that still don't get that good engineers are as precious as good lawyers.

No, the fact that myspace looks ghetto killed it.

I agree. That is why eBay is such a failure ;-)

- step 1 : create rules that makes it near impossible to develop

- step 2 : accuse the competency of developers to hide your own incompetency

- step 3 : fail

interesting consider Twitter is down right now.

Did "Closed Source" development kill MySpace?

tl;dr: No

if it contributed it was a much smaller factor than it's ugly design and skanky/teen vibe.

MySpace didn't die because of the Microsoft stack, they died because their users left for Facebook. I'd take the .NET stack over PHP any day of the week. I certainly don't know of any company that was so screwed by the performance of C# that they needed to create a C++ compiler for it. (HipHop compiler for PHP) PHP programmers aren't exactly known for their brilliance.

Definitely not a problem to fix their deploy problems on the .NET stack, I've put together automated deploys for Windows and with MSI they are a breeze. Yes, it's going to take a week or two to get the hang of WIX but after that the installer does all your dependency checks and you have a very repeatable process. If you stamp your MSIs with the build number it's even very easy to rollback.

This is just about the most monumentally stupid thing you can say, if you really don't like C# there are a dozen other languages available (like Ruby AND Python). If you're hiring people that can ONLY write code in one language then that should be a sign that you're not hiring the right people to begin with. They hired crap talent that happened to know C#

All this which stack scales best crap is cargo cult programming, you should recognize it as such. Most startups die because they have no customers, not because their servers are on fire from load.

now HN is just becoming /.

MS stack does not kill anyone. dumb management kills.

top level should be able to see the error and move, be it dumb layoffs or .net codebase. it's not like myspace was rocket science.

It's always been my understanding that spam is what killed MySpace. I'm sure Facebook's long-closed membership system helped make it a somewhat more manageable issue to deal with.

Yeah, uh, StackOverflow is written in ASP.NET.