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 was able to get Chromium compiling on my laptop (2010 MacBook Air) in a few hours using one of the tutorials on their Wiki. Most of my time was spent waiting for things to download and compile. Why would you need a VPS setup? If you want to do it in the cloud, isn't AWS enough?
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.
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.
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.
If you're an experienced developer, but the project you join requires a different toolset and/or set of executables than a previous one, then it'll take you a good while to get up to speed on it.
E.g. you've got Visual Studio the way you like it, but the new project has different code organization and code conventions and requires a different version of C++. You were developing for Android on Juno and now you're using GWT on Indigo. The libraries aren't checked in, and also Bob built them himself because he wanted to patch the logging library. The build system depends on ActiveState Python 2.5, it breaks in subtle ways if you use another distribution or version, but no one can tell you because they just all happen to have installed their copy when that was the latest.
[Remembered another one: we're using a library, but it's broken, and the workaround involves setting up absolute paths to a number of files in your user directory, and no one has a complete set of the necessary because we're all working on a different subset than you.]
A repo with dotfiles ain't gonna help you with any of that. I suspect that these scenarios describe the vast majority of development environments by quantity. It's a luxury to have your build environment be describable by a few text files whose location are known rather than bundled up in binaries, Windows Registry entries, and cargo-culted tribal knowledge. Yes, that's a horrible state of affairs, but to point the finger at "new developers" is to miss the point.
I agree that sometimes a new job might bring into light a toolset you;ve never used. I've never taken more than a day or two to get everything up to speed though. Interestingly enough, after being a unix guy for more than 10 years, my latest job required me to use visual studio. My first commit was three days after I started. This days I even have a file with all my VS configuration.
You also gave a perfect example of the only case I explicitly said you shouldn't point the finger to "new developers", which is when IT - or even the senior developers - are at fault for having a crappy development environment.
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.
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.
The other possibility is developers are given a computer that's in a locked down jail cell state. But pointing this out (and other configuration scenarios) distracts from the central idea: developers battle configuration hell because our processes are disconnected from each other. It's more than a configuration script, this is about solving a bigger problem. Think of remote development too and collaboration, this is something we can solve with cloud tooling.
So we should develop software on a development server. What a crazy new idea.
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!
Cloud9 does at least have an offline mode; so one isn't totally hosed if you're not connected or they go down. Granted, you can't actually run much, but it's still better than your entire display locking up if the network flakes out.
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.
If your new dev process isn't some close variation of:
1) Install IDE
2) Checkout code from repo
3) Run dev environment setup script
4) Open project in IDE
Absolutely. Development projects should have a repeatable, automated-where-it-makes-sense setup.
A few things I do at my company to make sure:
* give developers a new machine every 12-18 mos (depends on Apple refresh cycles). Forces everyone to install it fresh, and fix any dependency/install bugs to be fixed
* all new dev hires must have it running and have deployed a change on their first day.
* encourage graphic designers, QA, and other folk to get it running locally for testing and the like. The install script and docs must be super clear so it allows them to install it with minimal hassle
I was using Vagrant for this, but ultimately it didn't provide enough value to outweigh the overhead and hassle. A shame, but I think they are on the right track with their approach. Just needs a lot more polish in my opinion.
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.
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.
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.
I love your linked article because it addresses the intangibles of imparting the mental model of the code. Many times this is the delay when a new developer comes into an existing code base. While scripts and cloud tools can reduce or eliminate the configuration overhead, the programmer still needs to understand what the actual code is doing.
The last company I worked for had this problem initially. There were multiple layers of software that needed to be built and configured just so. If there was a problem with your build, it would take an hour to get and build everything from scratch if things went without a hitch. They often didn't.
This changed once we started using a build server and automated builds. This made a complete build script necessary. The benefit was that script could be used to both spin up a new dev environment (except for installing IDE and local database servers), and syncing the dev machine. Every morning I would run this script and let it chug along while I went to my standup and/or read my morning email.
I think an automatic configuration script combined with the pair programming idea, even if the programmers are paired for a day, would greatly speed up the new dev up the learning curve and allow them to be productive faster.
This is the weak link imo. The entire premise is that variance in developer preferences of environments is what leads to problems, but editors are where preferences tend to vary the most. If you're an open enough shop to not standardize systems, your devs sure aren't all going to want to be locked into the same editor.
In fact I'd guess most devs would be willing to sacrifice environment choice for editor choice if it came to that.
Or provide the five or so editors all. In a Unix shop, emacs, vim, eclipse, acme, and sam, with the popular plugins the current team members use, should satisfy almost everyone to get started.
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.
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.
Oh and of course the obligatory "You can have my emacs running evil-mode when you pry it from my cold dead hands".
