11–20 of 60 posts
This is a ridiculous myth that I wish we could just put to rest once and for all. If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. Even if hardware was free you still need to put it somewhere, power it, cool it and so on. There's no excuse for sloppy coding.
"Also, having programmers who believe that their employers actually give a damn about them is probably a good business strategy for companies that actually want to be around five or ten years from now." 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.
I applied to a job in the spring of 2006 and when they were showing me around the development area I noticed that everyone had single smallish CRTs and what seemed like older computers. I asked about it and they told me that most people had P3-500's! Unsurprisingly their salary offer was low also and I did not take the job.
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.
This is a ridiculous myth that I wish we could just put to rest once and for all. If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. Even if hardware was free you still need to put it somewhere, power it, cool it and so on. There's no excuse for sloppy coding.
This argument is applicable only to code that runs on only a small number of machines. Using roughly his numbers, you can afford to pay somebody US$100 000 to work for a whole year to make your code 10% faster if that code uses 100% of a million dollars' worth of hardware, which is only 200 high-end US$5000 servers or gaming machines, or 2000 low-end servers. But that's assuming that the benefit of the speed improvem…
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.
When I started as a programmer in the late 70s the relationship between hardware costs and programmer costs were just about the reverse to those described by Jeff. It was always cheaper to optimise the code than it was to invest in new hardware. I must admit that it is hard to shrug off the frugal approach to the hardware that I adopted at the start of my developer career - I think it still pays off to err on the sid…
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.
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.
This is a ridiculous myth that I wish we could just put to rest once and for all. If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. Even if hardware was free you still need to put it somewhere, power it, cool it and so on. There's no excuse for sloppy coding.
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.
This is a ridiculous myth that I wish we could just put to rest once and for all. If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. Even if hardware was free you still need to put it somewhere, power it, cool it and so on. There's no excuse for sloppy coding.
If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. 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.
This is a ridiculous myth that I wish we could just put to rest once and for all. If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. Even if hardware was free you still need to put it somewhere, power it, cool it and so on. There's no excuse for sloppy coding.
O(N^2) forgets that in most cases it's really more like K * O(N^2) + I and reducing the size of K can have dramatic impact because it tends to be more than 10,000 cycles. For a wide range of inputs a low latency N^2 can be faster than a high latency n * Log n because thrashing you cache is really bad. The basic question you need to ask is how much are you spending on hardware / bandwidth vs coders and which is better…
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).