Machine configuration is a hard problem. Having worked at a few different companies on a variety of platforms, one seemingly universal truth is that getting the application up and running he first time is never easy. From the dozens of configuration files that need to be written and the databases that need to be installed, loaded and migrated, to the keys, dependent libraries and source code - you'd be lucky to get everything up and running in your first week, and it will probably take months to really feel confident editing the code.
There's an entire ecosystem of tools related to this problem: machine imaging tools (Docker, Packer, Vagrant, ...), configuration management tools (Chef, Puppet, Ansible, Salt, Capistrano, ...), dependency management tools (Maven, Bundler & Gems, Pip & VirtualEnv, NPM, Cabal, NuGet, ...), build systems (make, cmake, SCons, Waf, Maven, Ant, SBT, MSBuild, ...), continuous integration servers (Jenkins, Team Foundation Server, Cruise Control, ...), and that's not even mentioning the myriad of cloud based solutions often built on top of these tools. It's a dizzying array of technologies: each with their own set of idiosyncracies and deficiencies.
Sadly the truth is I probably spend more time configuring machines than I do writing code: and that's probably just the nature of the beast when it comes to large, complex software applications.
But maybe not.
One way we end up making this whole process a lot harder than it ought to be is by multiplying the platforms we end up supporting. To take a common practice: most startups use some sort of open source stack running on top of (probably cloud-based) linux machines. They also usually give their developers fancy OSX-based laptops. These are radically different platforms (though thankfully not nearly as radically different as would be a Windows laptop). Everything from the way you install software, to the underlying available system libraries is in some way slightly different between the two.
Now building an application which can run on multiple platforms is certainly possible - most startups manage to pull it off. But it's one of those subtle differences which can add up to a configuration nightmare.
For example when I upgraded to Mavericks on my laptop it made it so that I couldn't install the version of therubyracer we use on some of our projects. This is because therubyracer depends on libv8, a compiled library which used C++ constructs which were incompatible with the clang compiler which Apple chose to link GCC to. (Why Rails would require an entire javascript interpreter is a different problem)
Of course newer versions of this library fix this problem, but they also broke our build, so I just figured out some hackish workaround to the problem. (StackOverflow is your friend) I figure out hackish workarounds like this all the time. It's just the reality of working on a complex system with many moving parts. But it sure seems a lot harder than it ought to be.
So what if instead of trying to move our application to our desired development environment, we moved our development environment to our application.
In recent years many tools have arisen which might just pull this off. Here are a few: Cloud9, Nitrous.IO, Koding, CodeEnvy, ShiftEdit, SourceLair, etc... A browser-based text editor is no longer a curiosity or future pipe-dream. It's very much a reality in the here and now.
Consider a setup I currently use:
There are a few cons:
And the pros:
I suspect that in the next few years the tools will improve dramatically. But even in their current state this is a legitimately viable option for development, and I kind of wish I had made the switch sooner.