".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.
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.
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.
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.
.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.
True, but different networks have different constraints and require different solutions. Data warehousing, which is likely what most of GS's data is doing, is very different than trying to scaling a near-real time data access system.
Payment processing only deals with one type of data: money. This gives you as many shortcuts as the number of constraints it imposes.
Airline control and departure systems are probably as close to a typical modern web app as you'd get from your list.
My point is that while there certainly are engineers that have worked with high scalability issues without ever touching the web, they have also likely been solving slightly different problems.
P.S.: Other systems that require high availability but are not the web: telephony and cell communications, broadcasting and doomsday devices.
According to this link (after a few seconds of googling), Visa's network was down for 8 minutes in the five years ending 2001. Do you have citations for any of your claims?
The Visa figure I heard at the Computer History Museum years ago, it was first decades so that may have changed.
Goldman Sachs told me when I was writing a proposal for them years ago that they have over a petabyte of data stored. The web is 80-200TB depending on who you ask. A single department there responsible for the program based trading would alone have an entire copy of the web (and parts of the deep web, and all of twitter, etc.) since they construct those whack trading apps that suck everything up and analyze it for signals. If there are any quants on here they could tell you about this more.
One of my professors told me YouTube is hosting approximately 100TB of new videos every month, I think 200 TB is off by very, very much. If 200TB was the case I could afford to buy disks to store the entire web with my yearly salary...
They don't have to add features quickly because they spend years designing and building them based on a spec that somebody else has spent years designing all so that when it launches, you can go online and book an airline ticket or make a transaction or whatever other essential daily activity and not have to think about what is taking place, let alone see an error screen or 404
no what I am saying is that it is unusual for them to get themselves in a situation where they have to suddenly code out of a hole at 'startup pace' (whatever that means)
startups don't have a monopoly on working hard or working fast, and it is arrogant to generalize about both .NET and enterprise developers in that way since we are all in one way or anther standing on the shoulders of earlier enterprise work (where do you think what we call 'nosql' and think is new and grovvy, was first used?)
Totally fair. First, apologies if it sounded like I was suggesting startups have a monopoly on working hard and fast. Of course I never meant anything like that at all.
Second, arrogant really isn't fair because I certainly never gave an assessment of my own abilities or value.
Third, totally.. .NET stands on the shoulders of the same stuff the infrastructure that runs most of the internet stands on. It's just that .NET doesn't run most (or even lots and lots of) the internet.. so to suggest that the .NET development community is less likely on average to be ready to build Facebook doesn't seem like blasphemy.
That's very different from suggesting the .NET camp isn't full of awesome, hard-working developers... but really, I apologize if it comes off that way. Definitely don't mean to suggest it in the least.
There's a flaw in your logic which makes it seem like blasphemy. It's not enough to say that there aren't many .NET examples; you have to show that the proportion of .NET people who do good .NET work is lower than the proportion of PHP/etc. people who do good PHP/etc. work. With PHP in particular, I would guess that it's easily true that a higher proportion in .NET would be better equipped.
Not good work. We're not talking about good work. We're talking about fast work that runs on the web, works at scale, and allows the organization to pivot easily. You certainly won't catch me suggesting PHP is some sort of awesome language.. it's not. But it's language that lives on the web, and if I was building something on the web and had my pick of a random .NET developer and a random PHP one, I'd take the PHP one... because chances are the .NET developer has never deployed something on the internet, and chances are the PHP dev has.
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 :)
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.
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.
> 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++ .
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.
I think I remember around 2005 being surprised at hearing PHP stand in for the P, before that it had always been Perl. Though it probably had to do with the circles you ran in.
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.
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.
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.
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.
The Microsoft stack is not always just a Microsoft stack any more. e.g. it has jQuery out of the box. Of course you mix and match when you get to the high end. The idea of the MS-only shop is not as true as it used to be, many people are more pragmatic.
I find it sad that these days MS is laggin behind
Why, because MS didn't supply every single piece of server infrastructure software that So use, just the main ones? That's an odd definition of "lagging".
MS have a distributed cache called "Windows Server AppFabric" (formerly "velocity"). I don't know that much about it.
I remember Velocity and articles on it initially. Thanks for the help. I am looking up AppFabric now.
See I prefer sticking with one flavor of tools because its easier for developers to adjust. TBH MS does supply almost everything from grounds up. I only had to look elsewhere for advanced distributed caching frameworks. In fact before switching to Amazon EC2 our old datacenter was running MS VMM and our stack still didn't have anything other than MS software.
MS does supply a product in each category, but most MS dev shops that I have seen will more often than not be using some of: svn instead of Tfs, nUnit instead of MStest, castle or ninject instead of unity, nHibernate instead of EF, etc. And targeting firefox/chrome with jQuery. As far as I know there's no clear leaders in the distributed cache niche, and there is a fair amount of interest in noSQL stores like mongo, couch and ravenDb.
Where the open source choice is more functional, cheaper or just more familiar, it often gets used instead. This is good.
All these new frameworks are designed to work with OSS tech. So lets say some better NoSQL platform comes out, it supports OSS technologies first. .Net comes later and sometimes it is difficult to decide which client library to pick to connect to the NoSQL service. OSS client libraries would mature early and .Net libraries would take a little time.
Connecting OSS tech and MS stack is getting easier but still leaves you with a lot of uncertainty.
tbh if you are running .NET and SQL Server you don't really need a cache like redis or memcache since SQL Server has had an in-memory query cache built in for 12+ years now.
Thinking that would help is a mistake. Take it from someone who went to optimize SQL Server 2008 R2 to its limits.
Cache framework's are absolutely necessary. The whole idea is to avoid a SQL Server hit and return a cached data object in memory. I think Stackoverflow is the best case study here.
Same here. Considering what can be done with careful tuning of hardware and database structure, I can tell SQL Server's limits are very high, but nowhere near close to whatever MySpace needed.
SQL Server is the third best Microsoft product. Right after their natural keyboard and their mice lineup.
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.
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.
Most .Net developers are working on intranet sites. They don't have problem with large footprint pages.
When they move to internet and public domain websites, they are newbies. It takes them a while to adjust to the way internet sites are written. SEO optimizations, CDN usage, Ajax calls etc are pretty important on internet site than on intranet site.
Imagine using a Update Panel to code for an internet website. It would create enough junk javascript to delay a page load but it works fine on intranet. To fix this jQuery or some other Javascript framework must be brought in.
Well, that's why if you're looking for a business model, here's something that works -- take intranet applications people commonly use and release alternatives that do not suck so much.
Companies like 37signals are doing it successfully ;)
The way you said it originally made it sound more like they simply don't think it matters. I think what you really mean is what you said here. They are newbies when dealing with high volume sites where page load time is critical.
IMO, that's a very different statement. One is a difference in experience with a domain, the other is ideological.
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.
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.
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.
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.
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.
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
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.
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.
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.
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 :)
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?
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.
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.
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...
> "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.
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.