I disagree. For starters, I care what I build my site in. I'd have a lot more fun using say python or (if I'm lucky) lisp or Haskell than I would using PHP. And more fun = easier.
Secondly, developers who might join your company are going to care. Developers are more than the technologies on their resumes. Good ones can learn new technologies quickly. And they might even be happier learning something new.
This view is typical of business people. There isn't anything wrong with that, and it's necessary to a certain degree. But as he scales up, I hope that he can find someone who can help him make a more informed technical decision.
(And for the record, this isn't necessarily targeted at ASP.NET. I can think of worse technologies to work with)
That's the thing though - you and I think programming is fun and awesome, whereas this guy thinks business is fun and awesome, and programming is just a means to do what he wants to.
What I think is a valuable lesson here though, is that he stayed focused on his goal of "put out the site", whereas with hackers it's easy to have a real goal of "Use technology X and write some awesome code" with a tertiary goal of "ship a product". Always be focused on getting your product out the door, even if you don't make perfect technical decisions.
Hey, wait a minute. Just what are you trying to say here? That business and technical people do better working together than ignoring each other? Next you'll tell me business people are human beings and not drones some cruel hacker made to torment other hackers.
It does not matter what you build, you can achieve the same with using either PHP, Python, Ruby or ASP.NET. I choose Python/Google App Engine, free hosting is what was important for me, so I learnt a bit of Python to build me sites http://initlabs.com
I agree. From the standpoint of what you can build a product using alone, any one of those is a good choice. However, I've learned that readability, along with being fun and efficient (from a developer productivity standpoint), is important, and the language makes a huge impact on all of these. I would argue that you can make say PHP readable, but it isn't necessarily going to be fun or efficient (but if someone can get all of those things, more power to them).
If you are hacking just for the sake of hacking then you are absolutely right. You should choose the technology based on how fun it is. But soon you will need to worry about how to pay the server and the bandwidth invoices. That time the business people's opinion will probably sound better.
Even for hacking, it is generally better to choose the technology that your core set of technical people are most comfortable with.
I think ASP.Net is a pretty smart move even if you do have a strong CS background and know a few other platforms. The basic reason is that Microsoft stuff performs really well and you won't have to worry about a lot of problems for a very long time.
Chances are one or two webservers will handle your page requests for quite some time before you need to start thinking about it. ASP.Net's sessions also work very well with server farms without much work beyond configuration you just need to follow a few rules and it works great.
Assuming you went with SQL Server 2008 then chances are your database is going to perform very well for quite some time. A DBA or consultant can come in when things get tough but any senior level developer who tries to act cool by pretending to be a DBA can keep things moving along until you have cash to pay someone to really make sure things scale well.
Plus no one cares. If your startup is moderately cool getting C# developers won't be tough either. I've met plenty of great C# developers so they're definitely out there.
I second that. I know quite a number of very high calibre C# developers and in my experience getting good C# developers to work on interesting projects has not been overly difficult.
I'm currently building a site in C# and deploying using mono on Linux. Very impressed with mono so far. My site has not been tested under high load, but nothing is suggesting to me so far that mono is not a viable option, and a solution which solves many of the problems pointed out in the article's comments.
.NET actually isn't that bad as far as performance and stability go. It's about on par with Java. It's much faster than scripting languages, and significantly more stable than Ruby.
Administering a Windows stack can sometimes blow, but the languages and virtual machines themselves are relatively solid.
More stable than Ruby? Rails may have started off quite leaky, but to call anything that's been put into production in the past 2 years unstable is just plain FUD.
Yeah, so this was my point. There's quite a stretch from ".NET isn't that bad" to choosing MSFT because it performs well. And nobody has any numbers or benchmarks or anything that back this up other than anecdotal evidence.
Downvote away, but it's silly to be listing performance and stability as an advantage to choosing MSFT, when at best it seems to be on par with its competitors.
Do you have any proof otherwise? I've developed software on numerous platforms, and the Microsoft stack was incredibly stable, and performed better than any Ruby/PHP/Python stack I've worked with.
I prefer to do most things in Rails these days, but I'm not kidding myself that for raw performance, .NET is great.
.NET languages are compiled. The compilers build an intermediate representation (IL, similar to bytecode in languages that use a VM) and they're just-in-time compiled when they're first loaded, so they run as native code. As an aside, one advantage is your assemblies automatically compile to 32- or 64-bit based on your platform, so you get "free" access to +4GB of memory if you're deployed to a 64-bit machine.
Java (for example) and C# benchmarks tend to be close because Java is very mature and, even though it runs on a VM, is highly optimized. It compares favorably with C for this reason.
The MS compilers are very good and Mono is catching up. If you run on Linux, you'll probably be slower than Java in many cases. That will change over time.
Stability is a different question. The stability of C#, F#, etc. is not related to Windows and IIS as platforms. You can run C# based web stacks on Linux.
I noticed that both examples of companies he didn't want to compete with talent for (Tumblr and Etsy) are NY companies, so I wasn't surprised to see his company is in Hoboken (just across the river from Manhattan).
The reality of course is in NY you're always competing for talent --- not just with the hot startups of the moment (Etsy, Tumblr, Foursquare, etc etc etc) but with the banks which are still paying big salaries for developers and solid benefits and bonuses.
The truth here - whether the author thinks the technology or not matters - is that he isn't competing at all for programming talent. He is competing for the kind of people who want to work at a hot startup, and have that mentality, versus a small one man shop. His statement "Hiring quality coders on a bootstrapper’s budget is easier for ASP.NET than it is for anything open source. It just is. " is telling.
Of course, its a completely unqualified unbacked statement.
But understanding the reality of what your talent shortages are caused by is important. I get the feeling that he went with the first technology he could hire people for cheap enough with.
"I don't know anything about programming, therefore my first choice is best."
Sure, that makes sense.
(It also follows from this logic that cheap programmers are a good thing to have. If you need to do twice as much work, you just hire twice as many programmers! Combined with an IDE, you're sure to succeed!)
Whenever someone says to use Java or .NET rather than the relatively obscure Ruby (or Node.js or whatever) because that makes it easier to find programmers, I always ask why they want to staff up on average to below average programmers. (Edit: sure there are good ones, just far more bad ones)
At least if they use the obscure language, you know that the programmer in question has his eyes and ears out there, finding things out on his own, trying things, reading stuff. There are a lot of cubicle programmers who simply don't; that find out about things when things are added to Visual Studio.
Not saying obscure languages are better in and of themselves (well, maybe just a pinch), just that the opposite isn't true. Easy access to droves of average to poor programmers is not a feature.
why they want to staff up on average to below average programmers
1. Because they don't want to spend a lot of time looking for developers - it's far easier to find a Java developer than, say, a Ruby developer, simply because there's so many of them. Also, because there is so many of them, in all likelihood they will ask for standard wages whereas a developer with a good knowledge of some lesser known language/technology might ask for a higher pay because he knows his skills are in demand and the employer cannot easily find somebody else with those skills for a lot less money.
2. For certain types of software there is no need to have the best of the best. Average programmers are just fine for working on a standard CRUD application. If you're Google and you're hiring people to work on your search engine, then yes, you want to have the most brilliant minds out there, but if you're a company that just needs somebody to maintain it's CRUD application than you'll do just fine with an average developer, who'll be more than happy to work for standard, average pay.
That being said, it's my opinion that, when hiring developers for work on an enterprise app, it's probably best to hire those that have a good knowledge of some enterprise-proven language like Java or C#, but with an interest in languages such as Scala, Ruby or Python. This way you get the guy that knows his way around an enterprise stack, but that's also not just a drone that considers programming nothing more than a day job, you get somebody who actually likes coding and frequently codes just for the fun of it.
> a developer with a good knowledge of some lesser known language/technology might ask for a higher pay because he knows his skills are in demand and the employer cannot easily find somebody else with those skills for a lot less money.
Given the huge productivity gulf between low and high ends of programmer productivity - a gulf that vastly outstrips the gulf between low and high pay levels - it stands to reason that as you move up the pay scale, programmers will tend to become net more productive in relation to what you pay them.
If you pay twice as much for a programmer who is ten times as productive, you end up ahead of the game.
You're going to find the full range of talent regardless of which language you're using. Erlang doesn't guarantee godlike competence, and .NET doesn't guarantee mediocrity. I think your biases are showing a little here.
I never said anything about a guarantee. I'm just saying that if you want to hire a programmer, the fact that there are thousands and thousands more of .NET programmers doesn't make hiring any easier. You want quality, not quantity.
I've never been able to figure that out, and yet many companies continue to do it. Some mistaken belief that a filled seat is better than an empty seat or something.
I don't think a startup that is not fundamentally technical has much to say about the merits of different technologies. This is a startup, and it's innovative, but it doesn't rely on the technology. Technology is just one piece of the puzzle for this kind of company. The company could succeed even if the technology were junk. Let's say he had a competitor who had a similar business model. They're competing on pricing models, advertising, convenience of shipping methods, turn around, and, yes, convenience and reliability of the website. But the last one is only a deciding factor if there's nothing more important in the other factors.
To summarize: nobody really gives a damn what you build your site in, if you aren't trying to do anything hard or innovative on the technology side.
Succeeding harder if the technology was junk is one assumption you might agree with.
Furthermore, from your list, anything that's not business is technology. Not every company ships physically, and those who don't just ship their product through the stack.
How fundamentally technical the startup is, is not decided by the owner but by the context. And technology matters there, a lot.
"I made a list of likely acquirers and then looked at what kind of programming skills they hire for. It was clear they all favor Microsoft. All things being equal it seemed logical to do the same."
and
"At the end of the day things just have to work and customers don’t give a shit what technology you built your site on."
If you're building a startup to "flip" it, isn't your future acquirer just as much a customer as your, er, customers?
The right answer is almost always to go with what you know best. As long as what you know best isn't completely ridiculous it will be the least of your problems.
I'm doing the same. I'll give a shout out to appharbor. They have made it insanely easy and cheap(as in free) to deploy a .net app.
...and here is a little secret that they may or may not want you to know...if you don't have the MS tools, it doesn't really matter. You don't even have to have windows. They build the code for you. You could used notepad to write an ASP.net app on their platform. Push. Test. Repeat.
You know why you don't have a good reason for choosing a language? Because you are a total programming newbie who hasn't actually tried to use other languages for anything!
If you use a better language, you will add features faster and spend less time fixing bugs, and you will be making the world a better place.
Your logic is naive at best, and awful at worst: "It just is." isn't an argument anyone should take seriously.
That doesn't really matter if in the PHP and .NET world you have to filter through 10,000 people to find somebody of the same median grade as you'd find in haskell/python/ruby/clojure.
I'm exaggerating for effect, but the take-home here is that if you don't have unlimited resources you need to have some way to differentiate and filter from the guys offering the sweet vacation packages and steady career options.
How exactly are you differentiating and filtering for higher quality people if not by technologies and developer freedom?
Do you have nice offices ala 37signals?
Are you an advocate of developer 'rights' such as Joel has been known to enumerate?
Why exactly should a dev tolerate using VisualStudio and Windows for the sake of working on your company?
Exactly. I know a recent startup that did their initial build-out in Lisp. Then the CTO left, for whatever reason, and then the remaining leadership team seemed to decide to rewrite the stack in Java. They probably thought, "Hey it will be easier to find people." Yes, it will be easier to find bad people. Are their great Java people? Of course. But the total number of resumes you're going to have to wade through, and the ratio of bad to good, is going to be much higher with Java than with Lisp.
Lots of things that you or I think are unique and special can be modeled as commodities. VCs model startups as commodities when they're preparing forecasts. Recruiters model high powered executives as commodities when they're preparing an interview pipeline. Like all abstractions, it's sometimes useful, and sometimes misleading. Certainly it's nothing worth getting excited about as a passing comment by the author.
I'm not quite sure that VCs model startups as commodities, considering that you get these huge pile-ons where everyone wants to invest in Twitter or Zynga but nobody wants to invest in the random startup your roommate founded. If startups actually behaved as commodities, brand names wouldn't matter so much.
Ditto high-powered executives - if they were actually commodities, executive pay wouldn't skyrocket through the roof.
You're missing the point. There are times when it's useful to model things as commodities, and times when it's not. Here, you see Union Square Ventures modeling startups as commodities:
but they would be the first to tell you that their investments are not treated as commodities when they're deciding on whether to provide follow-on investment.
Even traditional commodities - say, apples - are treated as commodities when they're being bought and sold in bushels. But when you go to pack your lunch, suddenly, you're inspecting for ripeness, bruises, etc.
Whatever you chose - is it really a good plan to write an article that amounts to "my startup was written by somebody who's new to coding in general. And the whole point is to flip it" ?
(Yes, I believe "exit strategy" is a fancy word for "built to flip".)
The biggest lesson I learned at my last startup is that your dev platform is an HR decision.
After the fact, I realized it would have been smart to at least check Indeed Trends to find out how niche our platform was. If you aren't seeing many jobs asking for CodeIgniter, just to use as an example, don't count on finding a lot of developers. If you have a good company, you're better off competing for talent head-to-head on a rising platform.
It doesn't quite work that way. Strictly speaking, you will find more developers if you choose the technology of the week or some other popular thing. But that doesn't mean that you'll find more good developers. They're difficult to find no matter what technology you're working with.
That said, you're on the right track as far as realizing that technology has an impact on who you hire. I would choose one more because it helps set you apart from other companies, not because it's what everyone else is using.
Having inadvertently chosen something (almost) no one was using, except us, I mightily regret not doing a sanity check to get the big picture. It made hiring really expensive and slow.
I'm a bit suspicious of their trends. It shows Perl significantly ahead of PHP, which is significantly ahead of Python. As a Perl programmer, I wish that were true, but I doubt it.
It also has COBOL ahead of Python up until 2008. I am skeptical of that.
I feel that the author just didn't try any other technologies.
> I found ASP.NET to be unmatched in terms of documentation
I find this hard to believe. Again I think the author knows his way around Microsoft products, and is biased towards it.
> Hiring quality coders on a bootstrapper’s budget is easier for ASP.NET than it is for anything open source. It just is.
I find this statement self-justifying and false. If a product is more scarce than others than it will probably be more expensive, in other words: if there is bigger competition there are lower prices.
The premise is true, no one cares about the server side technology expect maybe programmers who will have to build on that... wait what?
> I found ASP.NET to be unmatched in terms of documentation
I find this hard to believe.
Why do you find it hard to believe? ASP.NET is really well documented. Is it absolutely the best documented product in the world, but it is reasonable that someone doing an investigation could reasonably believe that ASP.NET has the best documentation.
I find it hard to believe if the author does not back it up with a lot of research and statistics. If the author would have just said 'it has great documentation' I would have said nothing about it, but when the compares it with others, he should have something to back it up.
As others have mentioned, using the term "unmatched" might be a stretch. I really wouldn't know the state of documentation for something like, lets say Lisp or Clojure, and probably the author doesn't either. But it's not up for discussion that .NET has a very comprehensive, high quality level of documentation, just take a look at MSDN.
I realize that there is probably great documentation for other open source frameworks as well, but I can see that it's likely Microsoft will always have great documentation on the very latest versions of their tools as they pay people to make the documentation, whereas OSS frameworks are more likely to rely on people to write boring documentation in their spare time.
My personal experience is that the MS stack is tough for a startup because Sql Server can get expensive... especially if you want uptime. The feature to rebuild the indexes (without downtime) and do horizontal partitioning requires the enterprise edition... and it retails at 25k/processor.
If you go with asp.net consider your budget before choosing sql server.
Most places can take the few minutes of SQL blocking resulting from an index rebuild in standard edition.
I know we often jump towards 5 9 solutions, because it feels like the "Right Thing(TM)" to do, but you can afford a lot of episodes of few minutes of blocking for what enterprise edition will cost... (we do run enterprise edition on our needed-by-cash-register DBs)
I'm a big fan of MS-SQL, and would encourage people to think about the value of chasing that 4th nine of uptime. It doesn't make sense for most companies, IMO.
Nothing stopping you using another database server - I've started using CouchDB with an ASP.Net MVC application because I wanted documented oriented storage and it works perfectly well.
MySQL seems to have plenty support, as does Oracle etc.
For those who are a solo developer and get strange requests such as "I demand this to be in ASP/PHP/etc." With whatever language you use, program away and modify .htaccess file to display the desired extension of .asp/.php/.etc.
Although I agree with the point that customers don't give a shit about the technology stack, did it seem to anyone else that he may be a little self-conscious about his choice of choosing ASP.NET? Read every single point. They all mention why he chose ASP.NET.
Edit: why the downvotes? I'm not saying that ASP.NET is a bad language. I'm just saying that his title doesn't agree with what he wrote.
You almost always have to rewrite your whole system anyway to scale to millions of users. It doesn't matter whether it's PHP, Python, C++, or ASP.NET; it'll have to be rewritten.
The real problem is the flip-side of something that the OP mentioned as an advantage: ASP.NET coders tend to be cheaper, less experienced, and hence less likely to know about some critical detail that'll boost adoption, whether it's usability or latency or security. As someone relatively inexperienced himself, the OP can't know what those things are, but it's highly likely that one of them will bite him.
In other words, it's correlation, not causation. ASP.NET won't make your site suck. However, ASP.NET biases your talent pool towards developers who suck, and that will make your site suck.
I'm curious how you conclude that ASP.NET developers suck ... there's a lot of shit programmers in all languages out there, that's why everyone's looking hard to find the rockstars/ninjas/whatevers.
You're looking for developers who have faced the problems that a typical web startup is likely to have faced as it grows and gains users. It is naturally easier to find those developers if you write it in a language that those current hot web startups frequently use.
To me this sounds like my friends who didn't want to go to UT because it 'was too big'. The awesome thing about too big is that if you look hard enough you are almost assured of finding someone like you.
Yes there are crappy c# developers. I've also seen some bad ass c#.
Right, "biasing your talent pool" doesn't mean that everyone in that talent pool sucks. There are certainly some very talented C#/.NET devs.
The problem is that when you go to hire, you have very little information about just how badass a prospective dev is, unless you've worked with them before. So if you take a random dev out of the C# pool, chances are he'll be worse than a random dev in the Python pool.
So if you take a random dev out of the C# pool, chances are he'll be worse than a random dev in the Python pool.
That was probably true in 1995. But not today. Python has become the new Pascal/Java. Commonly the intro language in CS, so you have a lot of students who graduate using Python regardless of skill.
If you said Haskell, then probably. Actually C++ maybe more then either, surprisingly.
Only if you assume that hits are evenly distributed throughout the day and throughout the month. Very few sites have that sort of traffic pattern. 30 million hits/month quite likely means peaks of 100 QPS followed by periods of 1 QPS.
My beef with ASP.NET is that it makes it disturbingly easy to write code that doesn't scale well and then is ridiculously hard to scale after the fact.
It really is all about the initial design not the language. ASP.NET just makes it too easy to go with bad design and library choices, not to mention the tons of examples of bad design that newbies might accidentally follow at the beginning.
Of course, you don't have to use the magic of WebForms (as I'm sure you know). You can use it just like 'MVC' where the code-behind class definition is the controller. In fact, now that I think about it, the big difference is that the controller-view mapping is static in WebForms (with code-behind) and dynamic in MVC (method loads a view).
Isn't this true of any language? ActiveRecord associations in Ruby on Rails are brilliant for getting code out the door, but the queries it produces along with complex lazy loading can make a database melt.
My beef with ASP.NET is that it makes it disturbingly easy to write code that doesn't scale well and then is ridiculously hard to scale after the fact.
Explain? Example? I don't see how this could possibly be true for .net but not for Rails or Python or PHP or whatever.
I think what noonespecial is probably getting at is that because .Net is usually written in Visual Studio a lot of people stick applications together in a RAD approach without giving much consideration for what is happening under the hood. Not all, of course, but probably a larger proportion that for platforms that don't have tools with RAD features like Visual Studio.
WebForms in ASP.Net are pretty much an attempt to take the developer experience of Visual Basic and make it work on the web - arguably with mixed results.
I really don't think there is anything wrong with .Net as a platform - but things like WebForms can be rather disturbing if not used with care.
Thanks -- it's such a good talk.
The final Q&A section of the talk is the best Q&A I ever saw.
Aside of tons of insights Joel was gently picking up on Googlers (e.g. by doing search using Bing).
You're right, .NET (even though I despise it) scales as well as anything else. Scalability is much more about design decisions than language/platform choice.
However, Joel Spolsky is a tool. Everyone I know and respect thinks he's a tool. He is a prime example of being successful because of being lucky, rather than being good. Do not quote Joel, he can't form a valid argument for a topic without circling back on himself to save his life.
Actually, that article is one of the most interesting and useful examples to point to when discussing the insanity that is Joel. That solution is just so ridiculous.
His software runs on a compiler that has had 2 months work put into it and worse, it compiles to either VBScript or PHP.
It's probably the most counter-intuitive solution ever implemented to solve the problem of needing a web-based application to run on both Windows and Linux.
Except when it came time to move to .NET/Mono, they only had to update their compiler to generate IL instead of rewriting the whole app from scratch. Sounds smart to me.
Except they are still stuck with any badly implemented language "features" in their own language that they only spent 2 months on. Language design and implementation is hard, just ask the dozens/hundreds of full time developers that work on ruby, java, php or .net itself.
Do you have inside knowledge of their framework? Did you know wasabi has memoization and heap of other things frameworks like .NET don't even have? They spent a lot more than 2 months on Wasabi. I think your information is outdated.
Whether Joel Spolsky is or is not a tool, lucky, good etc is completely irrelevant. He and the rest of the SE/SO team has built a highly scalable solution based on .NET. So in a discussion about scaling on .NET, it absolutely makes sense to listen to his experiences.
Actually, FogBugz is trivial to scale - there is never any more than a few dozen, to hundreds of users for any one project.
And Copilot wasn't even envisaged or created by Joel, but was rather a project created by some interns.
FogCreek doesn't innovate (they have a bug tracker and a remote support application based on VNC). Joel just happened to be one of the first to blog constantly about technology. He doesn't even allow comments on his posts because he doesn't want to have to deal with people contradicting him (not that he doesn't do an excellent job at this himself).
There are so many great developers and businesses out there that you could use as an example to model your business and software on. Use them, not Joel. Let Joel's business and opinions fade away as other smart, innovative companies run rings around his ageing product suite.
Someone approached hiwith the idea for that product, it wasn't his.
Besides, this is a perfect example of him contradicting himself about how taking VC is a bad idea.
Besides, do you think they are profitable yet? How do you think they will get there without heading down the Expert's Exchange track? And let's not forget how much chaff is now being added every day to these sites, it now seems to be impossible to ask a difficult question because only relative newbies seem to be the only ones answering questions.
I wish I could give you a 1000 up-votes for this. I'm so sick of hearing the rhetoric about language X not being able to scale.
Repeat after me, if your app doesn't scale it is YOUR fault, not a language, platform or framework. Scalability is about design and implementation, not what tools you use.
When you start out, you're designing your site in hopes that someone other than your mom is going to use it. Usually, all you need is an app server and a database. I you get successful, that won't cut it. You usually need to start adding more and more pieces and rethink some technology decisions you made originally.
I think I understand why the initial design/technology decisions would rarely make it to a product that has to be largely scaled. This makes perfect sense for almost all cases.
Do you think that there are technologies that are inherently more scalable than others, so if some body was initially choosing them would stand more chances to scale up in a non painful manner?
Worry about the "nobody cares enough" problem long before worrying about the "oh crap, too many people care" problem. User apathy, aka "not enough traction" kills far more startups than inability to scale. Pick the ecosystem with which your company will be most efficient and agile, and cross the scaling bridge if you come to it. We've rewritten substantially all parts of our codebase and key infrastructure 2 or 3 times in the last 8 years. You'll get the pleasure of doing the same iff you have users...
I completely agree with you. I think that in the 99.99% of the cases the question of scalability is related with a pseudo-problem or at best a good problem to have.
Bear in mind that developer experience and smarts count for more than anything else (if you don't have those yet, don't worry - they will come with time, patience, and effort).
That said, I would say that languages and technologies that help you achieve a more modular design will help you scale more. This makes it easier to tear things out and move them around so you can alter your architecture much more easily than you would otherwise. And of course efficiency (in terms of code performance) doesn't hurt either, but I wouldn't choose something on that alone. If you can have efficiency and modularity, so much the better!
It was Rails and, it wasn't that it wasn't unscalable but because they did it wrong then, they hired a bunch of developers that knew nothing about Rails, so of course they moved a lot of new and core development to other technologies.
It also had a lot to do with the fact that at the time Rails sites mostly ran on lighttpd or Mongrel, which was notoriously crashy (god was originally invented just to restart crashed Mongrels). From what I understand, at the time ActiveRecord hadn't yet been rewritten in C, which was also a big bottleneck for them (not to mention trying to scale MySQL to an insane level of traffic).
Nowadays, we have fancy stuff like Resque for background jobs, Passenger (aka mod_rails) for serving up Rails content, and a plethora of NoSQL databases.
ActiveRecord was never rewritten in C. Twitter's problems stemmed from the fact that they had written a realtime messaging system, but designed it like a microblogging platform. The design wouldn't have scaled well, regardless of the technology they used.
My beef with .NET is that the platform and community does not feel very organic like it is with others. Making a huge generalization, I would say that the .NET community waits around for the Mother ship to produce something that it can use. This was one impetus for the ALT.NET movement.
It was first created by non-MS guys, and there are others out there by community members. MS decided to form an officially-endorsed open source project for NuGet. Pretty good model actually. It's a collaboration of MS employees and community members and they take outside contributions. Not sure what's wrong with that. It needed to be in VS to take off.
The organic community is there, it's just not the dominant one but it has a significant presence.
>> It's a collaboration of MS employees and community members and they take outside contributions. Not sure what's wrong with that.
I agree, nothing wrong with that. I think a lot of the stuff that MS has been doing under Scott Guthrie in recent years has been very good in regards to fostering a better community.
>> It needed to be in VS to take off.
Do you think NuGet would be successful if MS had not officially endorsed the project?
Lots of things are successful without MS endorsement. If the integration had been as good as it was when it launched, yes. Only MS was willing to dedicate the resources to make that happen (VS addins, gallery site, etc).
Dan has all the qualities of a Microsoft employee - staff photo on blog (check), stripey shirt (check), called Dan (check), enterprisey design (check), wall of text (check).
Your endusers may not care. Not directly. But they'll care when your site has problems or is slow. This part, in turn, is heavily influenced by the quality of engineers you have behind the scenes, and the choices they make. The nature/quality of your engineers will be influenced by what kinds of technical choices are in place at the time you start trying to hire them on. As a general rule, for example, a LAMP stack is going to attract a different mix than a Microsoft stack would. Lisp will attract different than PHP. Therefore, tech does matter. Does it matter as much as making a product people want and are willing to pay for? Probably not as much. But if/when the time comes and you want your site to scale, or have lower problem rate, then your engineers and your tech are going to matter.
The absolute number one bottleneck in software-based startups right now is the availability, interest and affordability of good software engineers. The number and quality of engineers you're going to be able to attract will be heavily influenced by your tech choices upfront. There are some engineers who are so desperate they'll say yes to anything. There are others who have lots of choices and get to pick which to say yes too. In general, you'd rather have the second kind. So yes, tech does matter. The exact shade of the color blue you use in some image somewhere? Probably not matter too much. Your tech mix? Hell yes.
Secondly, developers who might join your company are going to care. Developers are more than the technologies on their resumes. Good ones can learn new technologies quickly. And they might even be happier learning something new.
This view is typical of business people. There isn't anything wrong with that, and it's necessary to a certain degree. But as he scales up, I hope that he can find someone who can help him make a more informed technical decision.
(And for the record, this isn't necessarily targeted at ASP.NET. I can think of worse technologies to work with)