One of the big challenges when you start a new company or bring someone new into the company is getting the environment set up so that you can commence or expand your business. This problem may never go away, because as much as we like to automate things, there are always things that need some manual adjustment or intervention. Setting up your software development environment, however, doesn't have to be one of those things.

Imagine that you wanted to build a build a system for dealing with customer trouble tickets (for the purposes of this example, imagine that we are building a web based solution and that the tickets are fed to the system through an external queue). Right off the bat, you know that there are going to be several components that will be involved with building this solution. You are going to have a UI front-end for the folks working the tickets, which means you will need some kind of server for answering web requests. You must interact with the message queuing system that feeds the tickets in, and presumably a similar queue system for sending messages about issue resolution. You will need a database or file store to track the tickets that come into the system.

Most developers will at the very least need to install build tools, code editors, source control management tools, the application server for serving the pages, and the database or file store solution for saving state. Anyone who has gone through the process of setting up a development environment knows that this process can take hours as you download each piece of software, install it, and configure it. If you work in environments where security is tight, you might not even have the ability to do these installs yourself, so you may have to file requests to have software pushed to you which can delay the process even further.

So how can we fix this issue so that your team can be productive sooner? One key way of doing it is through the use of virtualization. If I create a virtual machine image, download and install onto it all the software that I need, and configure that software, not only have I set up an environment for myself, I have also created a blueprint for other developers to use. They can copy the files that define that virtual machine and make it their own. They can customize it to their own needs and desires, but the starting point will be much further along the path. They also start with a known-good setup (and who hasn't run into the problem of a development environment that was setup incorrectly), so that even if they mess something up, they can always return to that starting point (or even save their own snapshots further along the path).

Cloud providers like Amazon and CodeEnvy have latched on to this idea and have even taken it a step further: virtual development environments in the cloud. You quickly specify the components you need and with a few clicks, things are spun up and ready to go. You can do everything in these virtual environments, including write the code, build it, debug it, test it, and even deploy it. Bringing someone on now becomes a relatively simple task of just spinning up a new environment and then showing them the ropes of how to start building and deploying your application. They might even commit code that gets deployed on their first day.

I'm glossing over details, and there are definitely still some steps that you need to take before you get to the point where creating new environments is so easy. The point is that by doing some extra work up front to set up these template environments, you empower your teams to jump right into the action and start doing what they really love doing, which is creating solutions. This is the future of development.