OK. If you're developing on a local instance of Apache/nginx sure. But as a professional web developer I usually have a fully virtualized dev environment running. That means, at least one of our app servers, our database server, and possibly a Windows VM (for testing in IE - usually I can save this for when I'm in the office and have all this stuff running on another machine).
For huge builds it makes sense to go with a compile farm. Working on a god box that sits idle 99% of the time is a bit wasteful.
A friend of mine tested it 3 years ago and it was something like 300% slower (no idea about the disk config, but he's a smart guy). It would have been worth it at anything under about a %50 hit...
It would have been a good fit for VMs.. except for the performance.
If you have to use a laptop, throw away the useless DVD drive and change it with a second HDD/SSD.
Many of the better laptops can also have a second mini-PCIE slot for an internal 3G modem. Install a modem there. This will help you a lot: 1) Internet access everywhere, 2) you don't have to worry about signal (the internal antenna is bigger and better) 3) you don't have to worry about crappy USB modems and their crappy drivers.
* The compilation is done remotely on a beefy server with no CPU/Disk IO/Disk space issues.
* I get several monitors. they don't even have to be big - 17 inch is fine - as long as there are at least two.
* The dev box is able to handle its software responsively. I souldn't have to reboot it. Ever. Hell any dual core with 2GB of ram, a linux distro + emacs would do.
Currenlty my 600 euro i7 box at home would probably put my work box and the team's remote compilation VM to shame. Both. At the same time...
Interestingly, from reading the comments i feel that startups are actullay more inclued to supply devs with good hardware than established players. I was expecting quite the opposite.
On most startups, the CEO's desk is, at most, a couple dozen steps away from the devs. It's the bean-counting professional managers that are brought in after that stage that make the developers miserable.
Since the code should be in a source control system, I don't see the point of this. RAID5 (increased redundancy and throughput) maybe, but even then you're increasing the chances of failure (the RAID hardware itself can fail) and you're not gaining much (if any) in the way of IOPS, which will be your biggest issue.
With Time Machine, you still have to manually rebuild your system after your drive fails. This is not what Time Machine is for; it's for, "oops, I shouldn't have deleted that file". (Which, incidentally, RAID is not for.)
Even a RAID1 failure requires you to have a replacement (ie, trip to Fry's). A bootable backup, however slow, is just there.
Also, you don't immediately need a replacement drive: RAID1 boots fine with only one device. Assuming your company policy is to have RAID1'd SSDs for all developers, you're probably going to have extras on the shelf anyway.
Time machine is for accidental data loss. RAID is for disk failures.
A nightly differential bootable system image backup a la SuperDuper, Macrium Reflect, Acronis or the like + cheap external 3TB drive = zero downtime... if the SSD fails, boot from external, and schlep it while the SSD is repaired/replaced.
Time Machine is bonus for lost/overwritten local files. Source Control guards the jewels (you don't fear committing untested code to local branch, do you?)
I think there are two requirements here: 1) redundancy of work in progress and 2) change control management. I want my work in progress to be relatively safe from failures, I want it to be automatic and I want to be able to choose which changes are worthy of their own revision number in version control. Personally, when committing work in progress I want my revisions to represent a logical stopping point and not necessarily dictated by how much time has elapsed since the last commit.
That way if you go down you can just swap the drive out and be on your way again.
This is what we do (and we have a lot of hard drive churn due to heavy use) and it works well.
For Linux / Windows folks, SuperMicro has a nice tower that has 4 hot swap hard drive bays that I really like.
Speaking only for myself... I have a gold disk plus a little script that syncs scripts and configs to backups. And I use Chrome logged into my Google account.
I do see your point, but a lot of it can be mitigated.
Well, our air-conditioner went out for 3 days in the middle of a Japanese summer, and the RAID controller itself shorted out, taking the drives with it. My boss still doesn't understand how we lost our data, because "RAID was supposed to protect our data."
- What is your standard developer hardware configuration?
- How often is it refreshed?
You get bad answers to those questions and it's a definite warning sign (IMHO).
If you're working for a cash-strapped startup (possibly bootstrapped), you may want to negotiate a deal whereby you supply your own hardware (in exchange for higher salary and/or stock/option grants) if they're only in a position to provide substandard hardware.
One side note: what constitutes good hardware depends on what you're doing. If all you're doing is writing PHP/Python/Ruby in vim/emacs and running a local Apache/nginx and possibly a MySQL server then it almost doesn't matter what hardware you have... apart from the monitor.
But if you're compiling huge C++ (or even Java) projects then you probably want good I/O (possibly an SSD, preferably in RAID1 config for redundancy), lots of RAM and a good CPU.
As one data point: I have a 6 core machine with 12GB of RAM and 2 24" monitors (some opt for 1 30") plus a Macbook Pro 15" with SSD. You can refresh your hardware every 18 months if you want to (but most don't unless they have a pressing need; I know some people with 4-5 year old workstations because those are fine for what they do).