How do you welcome new employees? Normally, it is a rite of passage that all new developers must search some documentation and struggle with setting up their development environment. Let me state for the record that I absolutely hate this concept. I understand the need for understanding the environment you are working in, but you really need to help people get started. This all stems from an interesting article regarding what the Cheezburger Network does for new engineers. In that post, they describe how they help get people started:

we provide them a document with a 17-step process for transforming their machine into a development environment.  This includes steps for installing software they will need to develop on our code base, for fetching our code from source control, and, finally, for building and running the code on their machine.  All in all, it takes about 90 minutes to get up and running (which includes installing an IDE and database server).

So, in 90 minutes a new employee can be ready to work. Even more interesting is that the new employee is immediately productive, “our new developers write and commit code to our production software on Day One”. Admittedly, that is damn impressive. Most of the time, you hear horror stories that people required a week to setup their development environment. Sometimes it is because they get minimal help if they are having problems or even because the documentation, if it exists, is almost useless.

The real question is the value of this exercise. If the developer will never need to setup this type of environment again, then this process is a useless time suck. If the knowledge of how to setup the environment will not help the developer in their daily work, again this process proves to be pointless. However, if part of the person’s job is to know exactly how all of these things are configured and how the pieces of the application interact, then the rite of passage is of great importance.

If the process is important, then what do you need to know? How much documentation is enough? Do you need a 17 step process that can be completed in 90 minutes? Probably not. However, you probably want the new developer ready to work after the first day. You need to remember that every day spent setting up an environment is a day that the developer is not developing any code. That can become very expensive. So, you need to find the balance of knowledge gained and developer expense.

First, remove the need for the developer to setup any IDE. This is a useless exercise unless you are developing plugins for the IDE itself. In most environments, there is a typical configuration that you would like the new developer to use. As an example, you might want the developer to install the most recent version of Eclipse with Mylyn and Subversion plugins, and you probably have some basic configuration, like code formatting, that should be included. Why not simplify the process and just provide the appropriately configured zip file or have a script that builds the appropriate configuration. You may spend a few days worth of effort creating this configuration, but you will likely save a day for each employee that is hired.

The same can be said of any datastore that is used. Why not prepackage the MySql installation along with the creation of the database and insertion of all the basic test data? You can easily script the installation and configuration of server software like Apache HTTP, Tomcat and JBoss. Again, it does not take much time to create scripts for this and the time savings help everyone involved.

So, if all of this can be preconfigured, what parts of the environment really need documentation? If there is a specific type of server software that only certain people use, or configuration is something that needs to be understood, then you should document the process instead of automating installation. The build process for the application should be documented, or be so easy that documentation is not necessary. The deployment, installation and configuration of the application being built should be documented as well. Most developers will need to install their application at one point or another, so it makes sense to spread knowledge of the process. Granted, much of the deployment and configuration of the developed application can and should be scripted to make the process simpler. But that simplification can be done after the knowledge is gained, and various configurations are tested.

As can be assumed by most of what I have talked about, the determination of how much to automate and how much to document is highly dependent upon the environment and the usefulness of the process. The best way to determine usefulness is a quick analysis of expected revenue and expense of the process. If the whole process of building a development environment takes 3 days, 2 of those days are spent installing basic things like Eclipse and Tomcat, and a developer costs the company $1000 per day, then the cost of this process is $3000 per developer. If you hire 100 developers per year, this will cost the company $300,000 per year. However, if only one day helps that developer generate revenue, then the other 2 days are wasted costs. You could spend 10 days creating scripts to automate the basic installation process as a one time cost, and add 1 day per month keeping these scripts up to date. This gives you $10,000 in initial costs, plus $12,000 per year in maintenance which could save $200,000 per year (2 days of 100 developers at $1000 per day).  I think most management teams would trade an initial $10,000 to save $188,000 per year.

If you look at those dollar figures, is your process really a needed rite of passage or are you throwing money away?