I'm about to ruffle some feathers.
Its an understatement to say that when you attack someone's beliefs they will naturally fight back. We all do it, and we all feel a need to do it, because the fact that something we have chosen to believe in at such an ingrained level has been questioned, can send us on a rampage of blind retaliation - no matter how much sense that person's words make.
We developers are no exception.
No different than a religious zealot, we tend to make up our minds about a particular subject and if someone questions that belief we lash out.
This can be about a specific form of development management or a chosen programing language.
By now you are probably wondering what it is I'm going on about.
Yesterday I met a colleague for a coffee break and we discussed possible directions for a new project.
During this meeting, while discussing the possible frameworks to choose from, I made an offhand statement - ASP.Net can't be scaled.
I didn't even think what I was saying at the time, I was simply stating what seemed to me as fact.
My colleague looked up from his coffee and simply asked - Do you stand by those words?
I paused, and said I do, though I had to ask my self if that is true.
I've spent the last day thinking this over and I realized that not only do I stand by those words I can explain why... this is no mere after thought.
Wait... whoah... but you just said?!?!
Yes, technically ASP.Net can scale. Technically.
But it won't.
For the sake of argument lets make a stupid assumption.
(Why stupid? Because it is wrong, but many entrepreneurs make this assumption when starting a new project, so we'll go with it).
When starting a new project you should choose one of the big names in web frameworks because these are proven in scale, and these are :Ruby on rails, DJango, MS.Net and Zend framework
What this admittedly silly but common assumption says is that the safest path is the trodden path and so we will choose one of four frameworks- two free frameworks supported by a community and two comercial frameworks supported by companies.
I'll refrain from making a comparison between these frameworks, god knows that subject has been debated to death, but I'll make my point about ASP.Net specifically.
What are the problems that will in effect prevent ASP.Net from scaling
I am a firm believer in the following theories and stand by them:
Closed solutions. Large corporations, such as the Governmental body I worked for for seven long years, believe that they should take a path which can most easily be measured and presented in a Powerpoint presentation to it's board of directors.
This in effect means that a comercial solution, supported by a comercial company (specifically in this case, Microsoft), is the safest choice - a big company will support any problem they find and will be more than happy to take millions of dollars in yearly consultation fees to make these problems go away.
There are many problems with this work assumption but the key problems, the way I see them are them, are that the project will now be dependent on above stated company no matter what.
This dependency can, and inevitably will, cost your project in both time and money which jeopardize it's success.
Comfort overhead. The strongest advocates of ASP.Net as a web framework talk about the ease of creating simple web pages quickly, with a very powerful IDE and an end to end solution for both your backend and frontend.
What these advocates seem to miss is this - no matter how hard you want to believe that a framework can be an end-to-end solution, it cannot.
Just as any developer who has worked for longer than a month can attest, the term "patch" will inevitably find it's way into our code's documentation at some point and one patch leads to another.
The overhead of a supposedly comfortable framework is that the more we hit a particular framework's wall of conformity (that invisible wall you hit when discovering that your chosen framework doesn't support what you want to achieve) manifests it's self in longer than normal development cycles and in unmaintainable code blocks.
This overhead also manifests it's self in other measurable costs - comfortable frameworks, that claim to save your developer time by doing a lot of the heavy lifting for him, tend to prove heavier in the long run by creating memory intense or code heavy components (did someone say Viewstate?) that create a real overhead in performance and costs.
But none of this is new.
These theories has been debated over and over again and many MS.Net advocates have retorted in many creative ways, many of them valid, and we still never endup with an actual answer.
This is where I'm about to ruffle some feathers
Theory number 3 is where things become really dirty.
Those who are now thinking that I have nothing new to say are compiling a love-hate response to my attempt to attack Microsoft's framework in an uninspiring fashion, but I'll ask them to wait a moment and read my next few lines, because they are the real reason for this article.
I have nothing against ASP.Net. I truly don't.
I have worked as a web developer for almost a decade, most of them spent in Visual studio's loving hands and I think Microsoft have built a very good framework.
And as many of the ASP.Net advocates will say, the framework can be scaled to support real scale. The framework supports a lot of very powerful HttpHandlers and HttpModules to control what is done by who and how he does it. You can easily bypass the bloated Page lifecycle and approach the project's development in the old fashioned scripting language style.
But that will never happen.
When I approach starting a new project and begin to think about future growth, developer recruiting and scaling problems I need to think about the limitations I may encounter on the way.
The sad truth about easy frameworks and closed solutions is that it dumbs down the developer community that uses them.
I'm not claiming MS.Net developers are dumb. Not at all.
I'm claiming that the developer community as a whole is less inclined to learning new approaches and new techniques. I'm claiming that when your entire work experience is built on closed solutions, whose bare bones and muscle tissue are hidden from you and your only knowledge of infrastructure is that which is preceded by a "system.Something" prefix, you will find it too easy to slip into mediocracy.
This means, that if I am recruiting ASP.Net developers, even if the developer community is the biggest in the business (which in Israel, is true) the chances of me finding a high quality developer, who understand what an HttpModule is and how to use it, are slim to none.
Especially if I need to compete with another one hundred CTOs searching for the same thing in the same pool of developers.
Inevitably I will find my self stuck with mediocre developers and big bills to Microsoft corp. for counciling fees.
This is why ASP.Net can only technically scale, because in effect it is too hard to find good quality developers who know how to bypass the framework's limitations once true scale is reached.
I am not saying these same problems don't exist with other frameworks, such as Rails or Django (Or web.py or Symphony etc.), but I do claim, that in the Israeli developer's landscape, the pool of developers working with Python or Ruby tends to be higher in quality and in understanding, when it comes to development challenges.
Where I get my heretic's ideas from
My theories are based both on experience and on blind belief, but I am not the only one who thinks this way, and I think that if you take a good long look at the Israeli Startup landscape you will find that our inventiveness and success is waining and that we need to take a good long look at the causes for this.
I recommend reading the Humus manifesto which seems to affirm my theories from a more experienced thinker.