Coding Horror: Hardware is Cheap, Programmers are Expensive
codinghorror.com
codinghorror.com
This is probably the most overlooked reason to get at least semi-good hardware. Part of the reason I quit my last job was because of management's stubborn refusal to get us tools that would make us be more productive.
If you have crappy pay and perks, then you won't attract good talent, and whatever good talent you had will eventually leave. Without good talent, it is highly unlikely you'll have a good app. If your app sucks, you will slowly bleed off customers, and revenue.
Of course, that's not a scientific fact. For exceptions start with: Contracts, Government.
I can't be too specific because we have some rather repressive libel laws over here.
Well, my project was wildly successful anyways and I ended up being moved to a proper office and he ended up getting a different job.
To be fair, the article is a little more balanced than the headline.
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.
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.
http://journal.dedasys.com/2008/12/04/the-economics-of-progr...
It's an extract from a paper from the 1950'ies by Backus (yeah, that Backus) saying pretty much exactly what Atwood says.
But that's assuming that the benefit of the speed improvement is merely improved throughput resulting in data-center savings. If the issue is that your non-AJAX UI is frustratingly and inconsistently slow and so your ex-customers have switched to your competitors' AJAX app because it has consistent 200ms response times when they click on buttons, it may not matter if their app actually uses more CPU cycles than yours (because half of it is written in JavaScript and your ex-customers aren't running Chrome yet.) If your game gets 20 frames per second and your competitor's game gets 35 frames per second with nicer-looking graphics, you're going to lose sales, even if the customers run the game for only 10 hours each.
And that's why gamer games and desktop apps are still written largely in C, C++, or Java with some Lua, and Google's large-scale apps are mostly written in C++ and Java, while small-scale server-based applications and the stuff developed by the in-house IT guys are written in all kinds of higher-productivity, lower-performance languages.
The last big app I was in charge of ran 1M pageviews a day on $500/month. At my standard rate, it isn't even worth a day of my time to double the capacity of my app on the same hardware.
He certainly isn't saying don't optimize. He's simply saying that scaling web apps STARTS with throwing hardware at the problem. Where and when you cut over to developer optimization depends on your -actual- costs, size, and growth.
For example, when you replicate databases, the replication overhead grows quadratically (n^2) to the number of servers. So, eventually you can't just throw hardware at it since eventually it's all overhead replicating between the servers and you can do any selects/updates/deletes. Most people will never get to this level and the article is probably written for people that won't have to deal with this.
So, at a certain level, you need to optimize your code to shard data, avoid joins, etc. because you simply can't throw hardware at it.
Most people will never get to that level so throwing hardware at the problem is often the answer, but if you have a lot of quadratic algorithms in your code, you're going to hit scaling problems that will make throwing money at it expensive to the point where you'll loose money.
A modern desktop app has a lot more expected of it than one from the 1980s (GUI, copy-paste with styled text & embedded objects, drag & drop, undo, etc), and that code costs time to link in, use, and let run.
When developing for the consumer market, hardware is not "expensive", hardware is simply not available: users control their hardware, and even the argument of "ever increasing gigabytes and gigahertz" doesn't work anymore, as more and more prefer to trade speed for increased portability or (surprise!) smaller price.
Hardware helps performance - but this only matters when more performance is needed. For example, if features or usability are needed, extra performance doesn't help. This is obvious, but it's surprisingly easy to get caught up in improvements that are better, but that don't matter.
For productivity of programmers, faster hardware only helps when performance is a problem. The article says: If [it] makes them merely 5% more productive... - that's an "if". Will a faster PC make you more productive? These days, compilation is too quick for me to squeeze in a swordfight. For other hardware (eg large screens) there is also a limit beyond which extra real estate isn't useful (Joel on Software talked about several of his coders that don't use their second monitor). It depends on the task, of course.
Faster is always cool and impressive. But like a 300 miles per hour station wagon, will it help you?
Write something that works. Run it at production loads. If it's not good enough, work on it. Don't worry about speed until you hit that. Only exception is if you know N's going to be big enough to be problematic.
In that case, do just enough optimization to make it reasonable.
Why? Optimization and maintainability* are often at opposing ends. It's best to avoid the costs of it when it's not needed, and the increasing capacities of computers should make you bias towards maintainability.
* and ease of debugging, and concerns for low software complexity, and likelihood that it will be well documented, and .....
As for memory opts, pass by reference instead of value (in C++).
I've sped up code by a factor of hundreds by doing some crazy stuff (without going to assembly).
it costs less to hire a skillful (but expensive) developer on ok machine than less skillful one(s) on expensive machine(s)
the 10-100x gain myth on skill is pretty much true