I've wondered about the "two week problem" in the context of large open source projects. It would be great if a developer could spin up, say, a temporary VPS for Chromium development, the toolchain all set up and source ready to modify. I can't be the only one with a pet bug that must be trivial to fix, but the overhead of setting up a whole new toolchain to do so is just not worth it.
I think this is probably a problem more with new developers vs seasoned developers. I've noticed that configurations woes plague people who haven't got to a point where they have already configured their environments to their liking tens of times. i can get a machine configured for development use in a few hours and be productive the next day. Why? Because I have a repo of all my latest dotfiles including my vim plugins and configs. I also have a list of software I need to download the moment I use a new machine in my 1Password notes. Lastly I have another note with all the stuff I usually change in OSX and Linux. I've even been thinking lately about make it even more streamlined by having scripts actually do all my work.<p>To get up to speed with my developing environment, I just need to sync a couple of dropbox folders on my dev machine, checkout my repos, or bring a usb (if not allowed to dropbox sync my stuff, in which case I'd really consider getting a job where I'm not limited by stupid policies that make little sense for developers) with my latest configs. Lastly I might spend a day configuring the companies environment architecture (svn I'm looking at you), but even in the worst situations this things are generally trivial.<p>For a developer, his machine should be free to configure to his liking as long as security constraints are taken into account. If the developer can't be up and running with his environment in a few days, he's either not experienced enough or the IT department utterly sucks. Generally, it's the first option.
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.
If your software really takes two weeks for an individual to configure and install, then perhaps you should look into providing a script or even a virtual machine image to automate the process. The strawman argument weakens the overall message that the author is trying to convey.
So we should develop software on a development server. What a crazy new idea.<p>There's these new things called "remote X11 displays" that might revolutionize the way we work on remote servers from local computers. If only it ran in a browser[1], though!<p>[1] <a href="http://lifehacker.com/287085/control-tightvnc-from-the-web" rel="nofollow">http://lifehacker.com/287085/control-tightvnc-from-the-web</a>
The problem is actually that most software projects are too complicated to setup. This is a kind of technical debt created by bad developers who think their job only involves coding, not maintaining the entire lifecycle of code. I bet these shops also have hard to reproduce builds and deploys that require dozens of human steps.<p>If your new dev process isn't some close variation of:<p>1) Install IDE
2) Checkout code from repo
3) Run dev environment setup script
4) Open project in IDE<p>then you're doing it wrong.
Misko Hevery (author of AngularJS) wrote a good blog post about how if you pair with a new hire for a day, you can bring them up to speed almost instantly. I tried it and it works - my new hires were committing real fixes by the end of day one.<p><a href="http://misko.hevery.com/2009/06/12/what-pair-programing-is-not/" rel="nofollow">http://misko.hevery.com/2009/06/12/what-pair-programing-is-n...</a><p>An additional benefit is that the experienced and more senior developer will also have to endure the pain of setting up, and the undocumented parts, and may even fix them.<p>However, if I was looking for a technical fix, I think using Vagrant is far better than anything cloudy. The cloud is a tradeoff - you get the benefits of virtualization, if you accept the downsides of it being all remote. The OP's solution doesn't even allow you to choose your editor! Vagrant gives you all the upside and none of the downside.
Maybe it's just me but I find the two week problem to be less about configuring my dev environment. Give me a sufficiently unix like box hg and I'm configured in less than 5 minutes.<p>It's more about getting up to speed the system I'm developing on and I have difficulty seeing how that can be properly abstracted out into a general solution.<p>Oh and of course the obligatory "You can have my emacs running evil-mode when you pry it from my cold dead hands".