9 ms·

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

".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.

sajidnizami 16y ago
I too work with sites hitting high visitor count but I have to agree there with the article. Most .Net people I've interviewed think page load speed doesn't matter. They write code to satisfy the requirement and are quite good at it, but it ends there. Remember when people used ASP.Net web forms and it was hard to get rid of viewstate in the rendered page, and only the people who knew internals of platform well could fix it. It drove SEO's mad and they started to recommend staying away from web forms. I agree with you on the staging and testing servers. Not having them is planning for disaster.
- famousactress 16y ago
  Sure.. maybe it's harder to build a top-notch .NET team than a LAMP one... but I think the point is that you have to know what a top-notch team and set of processes look like in order to build them... on any platform. If anything the tech-choices are symptomatic of a bigger issue.
- recoiledsnake 16y ago
  >Most .Net people I've interviewed think page load speed doesn't matter. Have you informed them that you work with a high traffic site? Most intranet sites are not high traffic, so if they're spending time pre-optimizing for speed instead of features/development time, they're actually wasting the company's money. And what has viewstate got to do with SEO? You lost me. For SEO friendly URLs, all you need a is URL Rewriter. http://www.google.com/search?client=opera&rls=en&q=asp.net+url+rewriter&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest http://www.google.com/search?client=opera&rls=en&q=a... >only the people who knew internals of platform well could fix it That's true of any platform out there.
  - PonyGumbo 16y ago
    In ASP.NET 4.0 and MVC, URL routing is built-in, and it's easy as pie.
  - sajidnizami 16y ago
    Something like this: http://stackoverflow.com/questions/1185984/is-viewstate-bad-for-seo http://stackoverflow.com/questions/1185984/is-viewstate-bad-... Yes I talk to them that we have a high traffic site and we lose them because they don't know about building them. Besides you won't find many Microsoft stack sites dealing with scaling issues. I personally looked up Stackoverflow scaling case studies to design my solutions later. Back in 2005/6 URL rewriting was still pretty difficult. I started out back then. I converted to MVC completely when 1.0 version came out specifically to address the SEO concerns. But I guess our discussion is swinging to technical side :)
  - pixelbath 16y ago
    SEOs prefer to have the "relevant content" as high on the page as possible. Since viewstate is just a large blob, many SEOs assume it decreases relevancy. I've never seen results that confirm this assumption. Edit: See sajidnizami's post for the relevant StackOverflow question. Though, this still doesn't make sense to me logically. Why would a search engine disregard a (reasonably) longer page?
    - sajidnizami 16y ago
      Longer page would increase page load time. A longer page with viewstate at the beginning would delay loading of content. Google penalizes pages that load slower. http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html http://googlewebmastercentral.blogspot.com/2010/04/using-sit...
- kenjackson 16y ago
  I too work with sites hitting high visitor count but I have to agree there with the article. Most .Net people I've interviewed think page load speed doesn't matter. I find this shocking and somewhat unbelievable. My wife, who isn't a tech person at all thinks that page load speed matters (she just called so I asked her) -- and sites gmail as an example of a page that takes too long to load (I think that "loading..." indicator actually brings their load time to the forefront, although it really isn't that long). I just have trouble seeing a .NET developer saying "for high volume sites page load speed doesn't matter", when most people who aren't in the tech industry would concede that it does.
  - sbov 16y ago
    I don't think they mean like that. If something is obviously slow its a problem regardless. However, especially when you have a certain number of users, even a fraction of a second faster load time can have a visible change in your analytics. I've read before that Facebook has shown that users tend to spend a fixed amount of time on their site. Once users hit that time limit, they're done. If your site exhibits similar usage patterns, the faster your pages load (even if they're already fast), the more users can get done on your site, which, depending upon your revenue model, may result in more revenue.
    - kenjackson 16y ago
      That information about fixed time usage is interesting. But even with that aside, doesn't everyone know that fraction of a second decreases in load time is important for high volume sites? For example, MySpace was getting at one point 24 billion page views per month. If you could reduce each page view by 1/100th of a second you save 40 weeks per month for your users (assuming the model where they look at a fixed number of pages). In the Facebook model, if you assume a page comes up in half a second, this delay results in a 2% decrease in page views -- which is a pretty huge deal when your business model indirectly revolves around page views. I guess my point is that even for people who come from a background where page load didn't matter. it would take 30s to point out it does, and I don't think you'd get any pushback.
- jcromartie 16y ago
  It's not so much that certain programmers don't think that page load speed matters; it's that the culture around the platform doesn't encourage speed. You're conditioned to not care anymore, because ASP.NET Web Forms makes it so damn hard to achieve responsive web apps, and building responsive web apps almost universally means breaking away from the standard ASP.NET Web Forms style of development. You have to abandon pretty much everything that makes the platform convenient in order to get good performance.
  - sajidnizami 16y ago
    Web forms were designed back somewhere around 2002 to compete with the likes of JSP etc. They still work well for their domain, which is intranet portal etc. MVC however is designed from grounds up to deliver speed and web standards compatibility. Building for web these days with Web Forms is just wrong. But yes, most to actually bend Web Forms to deliver requires wizardry.
  - StrawberryFrog 16y ago
    If your knowledge of ASP stops at webforms, then you have nothing to say about anything recent in ASP. It's all gone MVC and jQuery. StackOverflow is a good example.
- nikcub 16y ago
  You must be getting the shit end of candidates because I know as many brilliant C# developers as I do C, , PHP, Python etc. I also know plenty of terrible Ruby, Python etc. developers. You can not generalize based on the tool a developer uses based on you interviewing a handful of people oh and that viewstate forms thing from SEO is the SEO talking bullshit and trying to justify his job
  - sajidnizami 16y ago
    You are right about candidates. I had the same reaction to SEO at first. See SEO guy is partially right. It involved page load times. Larger viewstate means longer load time and that gets penalized by Google.
bradleyland 16y ago
As they say, "A bad workman blames his tools." It's really hard to say that they failed because of Microsoft tools. The fact is that they made bad decisions in how they would implement and use their tools. There's nothing to prove they wouldn't have done the same dumb things with open source tools.
- umjames 16y ago
  Exactly, a tool (technology-based or otherwise) is just a multiplier for the person wielding it. It's the people wielding the tool that make the difference. Management is not excluded from this either. They have to: 1. know, in depth, the business they are in and the tools they use (or could use) to achieve their goals 2. listen to what their team tells them and provide an environment where they can do the job right It sounds like there was a lot of micro-management and putting out fires in this case.
- IgorPartola 16y ago
  Precisely. How many terrible, awful, untouchable projects are out there that run on top of a LAMP stack? wordpress.com comes to mind with their thousands of servers dedicated to basically caching. I strongly believe that a terrible hacker will manage to foul up even the most beautiful language/framework, while a good hacker will be able to write neat and beautiful code in even the most obtuse and awkward languages. As for their actual infrastructure: not having a version control system and a build system (e.g.: never deploying directly from the VCS) is a must for any size team and sometimes even for single developers. Thankfully, nowadays most people do use VCS's but build and deploy systems are largely at the level of glorified shell scripts at best.
- deleted 16y ago
  [deleted]
monochromatic 16y ago
"whom" Yeah, that made me cringe too.
famousactress 16y ago
.Net programmers are largely Enterprise programmers whom are not constitutionally constructed to create large scalable websites at a startup pace. For the record, I think it's irrelevant.. but absolutely I think it's true. It doesn't mean .NET isn't capable, or that lots of .NET programmers aren't capable... Just that .NET is way more popular in the enterprise than on the web, and that the work that gets done at most of those enterprise shops wouldn't fly on large sites. It may be popular to pretend that the .NET camp (and to a slightly lesser extent, the Java Enterprise one) doesn't bend this way statistically, but they do.
- recoiledsnake 16y ago
  So PHP developers are "constitutionally constructed to create large scalable websites at a startup pace"? (Facebook had to a TON of stuff to make it scale). Ruby developers? (Ref: Twitter) Java developers? I think only HTML programmers are the only ones who are constitutionally constructed to create large scalable websites at a startup pace.
  - famousactress 16y ago
    Haha. Excellent point about HTML programmers. Also, it's probably fair to say that as a whole programmers are 'largely' not used to thinking or working in a way that's productive at scale. I didn't argue otherwise. I just suggested that the percentage of developers in the .NET community who are aligned with values, knowledge, and experience essential to scaling a large site.. is smaller than many other platforms... Yes, I'd argue smaller than all of the ones you mentioned.
- sofuture 16y ago
  Do you use .Net or are you familiar with the .Net community? Or are you basing your opinions on your lack of familiarity with it?
  - famousactress 16y ago
    I worked professionally on .NET very early on it's in existence, for a couple of years. Before that I was a COM developer for a couple of years... since then I've done 8+ years in Java shops, and now I'm a full time python dev. Most of my career has been in the enterprise space. The last couple of years have been in web. Most of my familiarity with the .NET community comes from the fact that I live/work in San Diego, and in the Healthcare IT space... if the combination of which don't make up the largest percentage of .NET developers in a particular area and arena, it must be close :) So most of my experience with the .NET community comes from knowing developers and working with .NET-turned-Java folks... It's true, I haven't done .NET in a very long time. That said, I made the same assertion (to a slightly lesser extent) about the Java Enterprise camp.. and I've got loads of experience with that :)
strlen 16y ago
> 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. Exactly. This seems to follow the Kevin Rose formula: make horrible decisions (or be entirely absent from decision making) without any understanding of technology, then blame your developers and technology choice ("Digg V4 failed to due to Cassandra"). If it weren't for Facebook's success, I can bet you'd see people blamining PHP for Digg's failure: prior to Facebook, P in LAMP also stood for Perl (and occasionally Python) and LAMP wasn't "universally" considered proven (unlike J2EE + Oracle or .NET + SQL Server), nor has Facebook been even remotely close to a "vanilla" LAMP site (since at least 2005)-- with many mission critical subsystems also being built in Java and C++ .
- rbanffy 16y ago
  > prior to Facebook, P in LAMP also stood for Perl The P in LAMP has been associated with PHP for much longer than the existence of Facebook.
  - strlen 16y ago
    I've always seen it stand for Python, Perl or PHP-- with many shops specifically stating "P for PHP" or "P for Perl". Yahoo hasn't settled on PHP vs. mod_perl (as a replacement for a C based template system filo built) until early 2000s and (when I was there) still had many Perl based services in production.
    - desigooner 16y ago
      When I interned at SBC/Yahoo DSL around 'mid 2000s, they used the LAMPerl stack quite extensively.
  - yesbabyyes 16y ago
    Maybe. We did LAMP before I heard the term, with a site in '98, but then it was definitely Perl. I've understood it as mainly Perl, and later PHP or Python as possibilities.
ww520 16y ago
Stackoverflow uses .Net stack and scales just fine, using less hardware as well.
- sjs 16y ago
  Plenty of Fish served 2m pageviews / hour with one server. http://plentyoffish.wordpress.com/2007/02/09/aspnet-and-iis-2-million-pageviews-per-hour/ http://plentyoffish.wordpress.com/2007/02/09/aspnet-and-iis-...
  - smokinn 16y ago
    Don't put too much faith in what Markus says. He lies about everything. Constantly. I think he thinks it's a strategic advantage to understate the work and resources he's invested into pof. (Makes for a good marketing story and newbies think building a pof clone is easy so they waste lots of money trying.) Right about the time that blog post was written peer1 had a marketing video on their site where there was a guy walking about a data center being interviewed by someone off-camera. As they walked around the guy waved at a few racks of servers and said these are plenty of fish's servers, walked further, these are [some other big web site].. And from that video it was clear there was no way he was only using 1 server. There were lots of servers in use.
    - MartinCron 16y ago
      POF uses a CDN, which runs on multiple servers, nobody has ever claimed otherwise. The claim (that I haven't seen disproven) is that it's one one application or one database server.
- rbanffy 16y ago
  Stackoverflow has a tiny fraction of the traffic MySpace had when it was relevant. I bet it has a fraction of its traffic now.
  - sajidnizami 16y ago
    StackOverflow's architecture these days is not just Microsoft stack. They are using Redis and whole load of other OSS tech to get things working. Here it is interesting to note that this is what they started with: http://blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/ http://blog.stackoverflow.com/2008/09/what-was-stack-overflo... and this is what they are currently using http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network http://meta.stackoverflow.com/questions/10369/which-tools-an... I find it sad that these days MS is laggin behind. It is difficult to get Cache frameworks and other infrastructure working with MS Stack if you got a high performance website.
jdavid 16y ago
As an ex-MySpace ID MDP employee we had staging servers. There were like 2 or 3 different levels of test, of course, that might have been unique to our team.
- kragen 16y ago
  Did you have version control? That's the most damning accusation to me.
  - ms_bitshifter 16y ago
    I don't even get where that accusation is coming from? Everything was versioned prior to building out, rather than allowing devs to drop dll's wherever they felt like it. Sure the local dev environment wasn't the best...
cabalamat 16y ago
> "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." And that, ladies and gentlemen, is why you don't want your software project managed by non-programmers. Any competent programmer would know not to do that.
deleted 16y ago
[deleted]
apedley 16y ago
Completely agree. Maybe they should have used Azure. At least that forces them into a staged deployment. (of course not that it was around when they started MySpace).
mkramlich 16y ago
> largely critical word there: largely. he wasn't saying all. he was making a generalization comparing large groups. individual cases may vary.
ms_throwaway 16y ago
There is so much garbage in those comments. The lack of staging servers was probably from 6 years ago and we use TFS, git and SVN.
- deleted 16y ago
  [deleted]

sajidnizami 16y ago

I too work with sites hitting high visitor count but I have to agree there with the article. Most .Net people I've interviewed think page load speed doesn't matter. They write code to satisfy the requirement and are quite good at it, but it ends there. Remember when people used ASP.Net web forms and it was hard to get rid of viewstate in the rendered page, and only the people who knew internals of platform well could fix it. It drove SEO's mad and they started to recommend staying away from web forms. I agree with you on the staging and testing servers. Not having them is planning for disaster.

famousactress 16y ago
Sure.. maybe it's harder to build a top-notch .NET team than a LAMP one... but I think the point is that you have to know what a top-notch team and set of processes look like in order to build them... on any platform. If anything the tech-choices are symptomatic of a bigger issue.
recoiledsnake 16y ago
>Most .Net people I've interviewed think page load speed doesn't matter. Have you informed them that you work with a high traffic site? Most intranet sites are not high traffic, so if they're spending time pre-optimizing for speed instead of features/development time, they're actually wasting the company's money. And what has viewstate got to do with SEO? You lost me. For SEO friendly URLs, all you need a is URL Rewriter. http://www.google.com/search?client=opera&rls=en&q=asp.net+url+rewriter&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest http://www.google.com/search?client=opera&rls=en&q=a... >only the people who knew internals of platform well could fix it That's true of any platform out there.
- PonyGumbo 16y ago
  In ASP.NET 4.0 and MVC, URL routing is built-in, and it's easy as pie.
- sajidnizami 16y ago
  Something like this: http://stackoverflow.com/questions/1185984/is-viewstate-bad-for-seo http://stackoverflow.com/questions/1185984/is-viewstate-bad-... Yes I talk to them that we have a high traffic site and we lose them because they don't know about building them. Besides you won't find many Microsoft stack sites dealing with scaling issues. I personally looked up Stackoverflow scaling case studies to design my solutions later. Back in 2005/6 URL rewriting was still pretty difficult. I started out back then. I converted to MVC completely when 1.0 version came out specifically to address the SEO concerns. But I guess our discussion is swinging to technical side :)
- pixelbath 16y ago
  SEOs prefer to have the "relevant content" as high on the page as possible. Since viewstate is just a large blob, many SEOs assume it decreases relevancy. I've never seen results that confirm this assumption. Edit: See sajidnizami's post for the relevant StackOverflow question. Though, this still doesn't make sense to me logically. Why would a search engine disregard a (reasonably) longer page?
  - sajidnizami 16y ago
    Longer page would increase page load time. A longer page with viewstate at the beginning would delay loading of content. Google penalizes pages that load slower. http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html http://googlewebmastercentral.blogspot.com/2010/04/using-sit...
kenjackson 16y ago
I too work with sites hitting high visitor count but I have to agree there with the article. Most .Net people I've interviewed think page load speed doesn't matter. I find this shocking and somewhat unbelievable. My wife, who isn't a tech person at all thinks that page load speed matters (she just called so I asked her) -- and sites gmail as an example of a page that takes too long to load (I think that "loading..." indicator actually brings their load time to the forefront, although it really isn't that long). I just have trouble seeing a .NET developer saying "for high volume sites page load speed doesn't matter", when most people who aren't in the tech industry would concede that it does.
- sbov 16y ago
  I don't think they mean like that. If something is obviously slow its a problem regardless. However, especially when you have a certain number of users, even a fraction of a second faster load time can have a visible change in your analytics. I've read before that Facebook has shown that users tend to spend a fixed amount of time on their site. Once users hit that time limit, they're done. If your site exhibits similar usage patterns, the faster your pages load (even if they're already fast), the more users can get done on your site, which, depending upon your revenue model, may result in more revenue.
  - kenjackson 16y ago
    That information about fixed time usage is interesting. But even with that aside, doesn't everyone know that fraction of a second decreases in load time is important for high volume sites? For example, MySpace was getting at one point 24 billion page views per month. If you could reduce each page view by 1/100th of a second you save 40 weeks per month for your users (assuming the model where they look at a fixed number of pages). In the Facebook model, if you assume a page comes up in half a second, this delay results in a 2% decrease in page views -- which is a pretty huge deal when your business model indirectly revolves around page views. I guess my point is that even for people who come from a background where page load didn't matter. it would take 30s to point out it does, and I don't think you'd get any pushback.
jcromartie 16y ago
It's not so much that certain programmers don't think that page load speed matters; it's that the culture around the platform doesn't encourage speed. You're conditioned to not care anymore, because ASP.NET Web Forms makes it so damn hard to achieve responsive web apps, and building responsive web apps almost universally means breaking away from the standard ASP.NET Web Forms style of development. You have to abandon pretty much everything that makes the platform convenient in order to get good performance.
- sajidnizami 16y ago
  Web forms were designed back somewhere around 2002 to compete with the likes of JSP etc. They still work well for their domain, which is intranet portal etc. MVC however is designed from grounds up to deliver speed and web standards compatibility. Building for web these days with Web Forms is just wrong. But yes, most to actually bend Web Forms to deliver requires wizardry.
- StrawberryFrog 16y ago
  If your knowledge of ASP stops at webforms, then you have nothing to say about anything recent in ASP. It's all gone MVC and jQuery. StackOverflow is a good example.
nikcub 16y ago
You must be getting the shit end of candidates because I know as many brilliant C# developers as I do C, , PHP, Python etc. I also know plenty of terrible Ruby, Python etc. developers. You can not generalize based on the tool a developer uses based on you interviewing a handful of people oh and that viewstate forms thing from SEO is the SEO talking bullshit and trying to justify his job
- sajidnizami 16y ago
  You are right about candidates. I had the same reaction to SEO at first. See SEO guy is partially right. It involved page load times. Larger viewstate means longer load time and that gets penalized by Google.

bradleyland 16y ago

As they say, "A bad workman blames his tools." It's really hard to say that they failed because of Microsoft tools. The fact is that they made bad decisions in how they would implement and use their tools. There's nothing to prove they wouldn't have done the same dumb things with open source tools.

umjames 16y ago
Exactly, a tool (technology-based or otherwise) is just a multiplier for the person wielding it. It's the people wielding the tool that make the difference. Management is not excluded from this either. They have to: 1. know, in depth, the business they are in and the tools they use (or could use) to achieve their goals 2. listen to what their team tells them and provide an environment where they can do the job right It sounds like there was a lot of micro-management and putting out fires in this case.
IgorPartola 16y ago
Precisely. How many terrible, awful, untouchable projects are out there that run on top of a LAMP stack? wordpress.com comes to mind with their thousands of servers dedicated to basically caching. I strongly believe that a terrible hacker will manage to foul up even the most beautiful language/framework, while a good hacker will be able to write neat and beautiful code in even the most obtuse and awkward languages. As for their actual infrastructure: not having a version control system and a build system (e.g.: never deploying directly from the VCS) is a must for any size team and sometimes even for single developers. Thankfully, nowadays most people do use VCS's but build and deploy systems are largely at the level of glorified shell scripts at best.
deleted 16y ago
[deleted]

monochromatic 16y ago

"whom" Yeah, that made me cringe too.

famousactress 16y ago

.Net programmers are largely Enterprise programmers whom are not constitutionally constructed to create large scalable websites at a startup pace. For the record, I think it's irrelevant.. but absolutely I think it's true. It doesn't mean .NET isn't capable, or that lots of .NET programmers aren't capable... Just that .NET is way more popular in the enterprise than on the web, and that the work that gets done at most of those enterprise shops wouldn't fly on large sites. It may be popular to pretend that the .NET camp (and to a slightly lesser extent, the Java Enterprise one) doesn't bend this way statistically, but they do.

recoiledsnake 16y ago
So PHP developers are "constitutionally constructed to create large scalable websites at a startup pace"? (Facebook had to a TON of stuff to make it scale). Ruby developers? (Ref: Twitter) Java developers? I think only HTML programmers are the only ones who are constitutionally constructed to create large scalable websites at a startup pace.
- famousactress 16y ago
  Haha. Excellent point about HTML programmers. Also, it's probably fair to say that as a whole programmers are 'largely' not used to thinking or working in a way that's productive at scale. I didn't argue otherwise. I just suggested that the percentage of developers in the .NET community who are aligned with values, knowledge, and experience essential to scaling a large site.. is smaller than many other platforms... Yes, I'd argue smaller than all of the ones you mentioned.
sofuture 16y ago
Do you use .Net or are you familiar with the .Net community? Or are you basing your opinions on your lack of familiarity with it?
- famousactress 16y ago
  I worked professionally on .NET very early on it's in existence, for a couple of years. Before that I was a COM developer for a couple of years... since then I've done 8+ years in Java shops, and now I'm a full time python dev. Most of my career has been in the enterprise space. The last couple of years have been in web. Most of my familiarity with the .NET community comes from the fact that I live/work in San Diego, and in the Healthcare IT space... if the combination of which don't make up the largest percentage of .NET developers in a particular area and arena, it must be close :) So most of my experience with the .NET community comes from knowing developers and working with .NET-turned-Java folks... It's true, I haven't done .NET in a very long time. That said, I made the same assertion (to a slightly lesser extent) about the Java Enterprise camp.. and I've got loads of experience with that :)

strlen 16y ago

> 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. Exactly. This seems to follow the Kevin Rose formula: make horrible decisions (or be entirely absent from decision making) without any understanding of technology, then blame your developers and technology choice ("Digg V4 failed to due to Cassandra"). If it weren't for Facebook's success, I can bet you'd see people blamining PHP for Digg's failure: prior to Facebook, P in LAMP also stood for Perl (and occasionally Python) and LAMP wasn't "universally" considered proven (unlike J2EE + Oracle or .NET + SQL Server), nor has Facebook been even remotely close to a "vanilla" LAMP site (since at least 2005)-- with many mission critical subsystems also being built in Java and C++ .

rbanffy 16y ago
> prior to Facebook, P in LAMP also stood for Perl The P in LAMP has been associated with PHP for much longer than the existence of Facebook.
- strlen 16y ago
  I've always seen it stand for Python, Perl or PHP-- with many shops specifically stating "P for PHP" or "P for Perl". Yahoo hasn't settled on PHP vs. mod_perl (as a replacement for a C based template system filo built) until early 2000s and (when I was there) still had many Perl based services in production.
  - desigooner 16y ago
    When I interned at SBC/Yahoo DSL around 'mid 2000s, they used the LAMPerl stack quite extensively.
- yesbabyyes 16y ago
  Maybe. We did LAMP before I heard the term, with a site in '98, but then it was definitely Perl. I've understood it as mainly Perl, and later PHP or Python as possibilities.

ww520 16y ago

Stackoverflow uses .Net stack and scales just fine, using less hardware as well.

sjs 16y ago
Plenty of Fish served 2m pageviews / hour with one server. http://plentyoffish.wordpress.com/2007/02/09/aspnet-and-iis-2-million-pageviews-per-hour/ http://plentyoffish.wordpress.com/2007/02/09/aspnet-and-iis-...
- smokinn 16y ago
  Don't put too much faith in what Markus says. He lies about everything. Constantly. I think he thinks it's a strategic advantage to understate the work and resources he's invested into pof. (Makes for a good marketing story and newbies think building a pof clone is easy so they waste lots of money trying.) Right about the time that blog post was written peer1 had a marketing video on their site where there was a guy walking about a data center being interviewed by someone off-camera. As they walked around the guy waved at a few racks of servers and said these are plenty of fish's servers, walked further, these are [some other big web site].. And from that video it was clear there was no way he was only using 1 server. There were lots of servers in use.
  - MartinCron 16y ago
    POF uses a CDN, which runs on multiple servers, nobody has ever claimed otherwise. The claim (that I haven't seen disproven) is that it's one one application or one database server.
rbanffy 16y ago
Stackoverflow has a tiny fraction of the traffic MySpace had when it was relevant. I bet it has a fraction of its traffic now.
- sajidnizami 16y ago
  StackOverflow's architecture these days is not just Microsoft stack. They are using Redis and whole load of other OSS tech to get things working. Here it is interesting to note that this is what they started with: http://blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/ http://blog.stackoverflow.com/2008/09/what-was-stack-overflo... and this is what they are currently using http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network http://meta.stackoverflow.com/questions/10369/which-tools-an... I find it sad that these days MS is laggin behind. It is difficult to get Cache frameworks and other infrastructure working with MS Stack if you got a high performance website.

jdavid 16y ago

As an ex-MySpace ID MDP employee we had staging servers. There were like 2 or 3 different levels of test, of course, that might have been unique to our team.

kragen 16y ago
Did you have version control? That's the most damning accusation to me.
- ms_bitshifter 16y ago
  I don't even get where that accusation is coming from? Everything was versioned prior to building out, rather than allowing devs to drop dll's wherever they felt like it. Sure the local dev environment wasn't the best...

cabalamat 16y ago

> "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." And that, ladies and gentlemen, is why you don't want your software project managed by non-programmers. Any competent programmer would know not to do that.

deleted 16y ago

[deleted]

apedley 16y ago

Completely agree. Maybe they should have used Azure. At least that forces them into a staged deployment. (of course not that it was around when they started MySpace).

mkramlich 16y ago

> largely critical word there: largely. he wasn't saying all. he was making a generalization comparing large groups. individual cases may vary.

ms_throwaway 16y ago

There is so much garbage in those comments. The lack of staging servers was probably from 6 years ago and we use TFS, git and SVN.

deleted 16y ago
[deleted]