[msurel]

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.

[bartonfink]

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.

[boomzilla]

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".

[Evbn]

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?

[neilk]

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.