It was hard for me to get past the 'two week' problem being the opening argument for this. It has never taken me 2 weeks to get any machine configured and ready to go. I agree with cmwalsh in that this drastically weakens the overall message. The only reason I continued past the 2nd paragraph is because this was linked from HN. My initial response would normally be "Who really takes 2 weeks to configure a machine??" and then move on to something else worth reading.
I've seen that happen, but only due to some exceedingly bad environmental and architectural issues. Poor SVN management was the chief problem - there were around 100 interdependent repositories that had to have certain versions built and linked in as libraries depending on what you'd actually be working on.
Hiring a new person and finding that literally nobody could get them set up to develop in a reasonable time frame led directly to cleaning those issues up.
You never worked with a service oriented environment, right? When you need to override dozens of services your build/local instance depends on, it could easily take a couple of weeks, especially for fresh graduates who used to "./configure && make && sudo make".
Why don't your configuration files have service client configs on them?
Does it take two weeks to deploy a build to a production machine or the integration test farm? No. Then why would it take two weeks to pushh the code to a dev machine?
It's taken me more than two weeks in some cases. Because after a week of thrashing, a new hire will quite rightly get panicky if they aren't yet writing code. So one may just give up and accept a machine in a 'limping' state.
When I was younger and stupider, I accepted a 'limping' dev box for months at a particular new job, because everything was undocumented and I was afraid to ask for help.
