Well, that depends on the value of n, right? Not every piece of software is Google or Twitter: They don't all have a userbase that grows virally to encompass every breathing human in existence, plus animals and robots. Especially if you charge the users money.
Worse, almost all software isn't like a Google or Twitter. In almost all cases hardware is vastly cheaper than programmers. The Googles and Twitters of the world are extreme outliers and are no where near the median.
The average irc server probably handles more than twitter - certainly email software does.
There's a ton of software that needs to scale, and be able to handle a large volume of data.
http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi...
(Many thanks to Eran Hammer-Lahav for writing this so that I don't have to.)
The problem is that where once it would have been written in c as a server, it's now written with big databases and 'popular' languages - so it's harder to scale.
But a message server in Ruby with Eventmachine wouldn't have been that hard, would it?
There are better ways: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc...
For a good introduction check out http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-...
Yes, but there's vastly more that doesn't, you need to stop thinking that most software runs on the Internet and has tons of users, it doesn't. The vast majority of software is written for businesses and runs either on an intranet or is available on the internet to the users of that business.
For every public app you know about that needs to scale there are a hundred you don't know about that don't need to scale. Most programmers work on systems that will never need to scale, EVER. It is a tiny tiny minority of programmers that actually work on systems that become publicly popular on the Internet and actually face scaling issues.
Secondly, we're talking about programmers here, not the software, most email systems use existing mail software written by that tiny tiny minority of programmers who write such systems. The vast majority of programmers will NEVER write a mail system, a chat system, or anything that handles large volumes of data or users. Most of them of doing one thing, biz apps for in house projects at big and small companies exposing relational data to in house users.
How many IM networks are there? Now how many programmers are there? I'll say it again, most software does not need to scale. Because a lot of software does need to scale does not make that statement in any way false because a shit load more doesn't need to scale.
That doesn't mean a thing in terms of scalability. One user can max out a fast machine with OLAP cubes or other DSS. Or any sort of simulation or modeling. Think in terms of datasets, not in terms of users (all many users are is a large dataset with a requirement for a quick turnaround of each computation).
scalable - How well a hardware or software system can adapt to increased demands.
scalable - the ability of a product or network to accommodate growth
The ability to scale hardware and software to support larger or smaller volumes of data and more or less users.
the ability of a computer system to shrink or grow as requirements change
If you want to be able to handle any value of n, and expect it to be large, you should care about O(n^2) algorithms. You don't have to necessarily get rid of them all at once, but you should at least know where they exist and have them listed as possible pain points or places to start optimizing.
To be fair, the article is a little more balanced than the headline.
The basic question you need to ask is how much are you spending on hardware / bandwidth vs coders and which is better to focus on.
In this case, I'd say you need programmers to reduce the O(N^2), and hardware to reduce the K.
If you can reduce K by 50% for $5,000, then it makes almost no sense to use a programmer to reduce K. However, hardware will almost never save you from a programmer who gives you an O(N^2) instead of a log N solution.
This happened at my last job (actually, worse). Management decided I would be an "Architect" and train an offshore team to write the code (hmm... seems kind of fishy). We were building a system that would hold an equation with millions of constraints and variables, and we needed to be able to look up a variable value by name.
The code from the offshore team, no kidding, stored them in arrays. Unreal. I quit, for all kinds of reasons.
(yes, yes, many offshore teams could have written this code very well - the problem was not offshore programmers per se, it was that mgmt wanted top talent for cheap and was outsourcing its core product, and you don't get something for nothing).
If you need to scale, you need to have a good architectural path from the beginning. I've talked to too many companies whose growth is constrained by the need to re implement from the ground up, right in the middle of the hockey stick growth. What I mean is a little bit of thought at the beginning, not months of agonizing or 9 tons of frameworks. Given that, you can throw hardware at it and let your programmers add value.