Re:The Two Week Problem
by msurel on Monday August 20, 2012 @02:53PM
(#4409160)
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.
[ Parent
| on HN ]
Re:The Two Week Problem
by bartonfink on Monday August 20, 2012 @03:25PM
(#4409326)
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.