How long does it take for you get a new developer in the door, sitting at a desk, productively coding? How long? A few days, multiple weeks? If you are developing enterprise systems, the answer is probably closer to a week than a day. A developer has to download a large, daunting list of tools, configure source control, and understand an often highly customized build system.
This particular inefficiency is the proverbial "elephant in the room" because you have to actively ignore how much time a team of ten or a hundred developers spends installing, reinstalling, tweaking, experimenting with, and arguing over different development environments. We've automated almost every other aspect of the enterprise, but the developers are still hand-crafting custom workstations.
When Sonatype was doing research for Maven Studio for Eclipse we followed a few programmers through the process of onboarding. From start the finish, the worst case took a week and a half and the best case took less than a day. The one thing in common with almost all of the onboarding processes we witnessed were poor or nonexistent documentation and a reliance on "word-of-mouth" infrastructure configuration. A new developer would show up on Day One, fill out some HR forms, and then be thrown at a new workstation with nothing more than an Operating System and a Mail client. It would be up to him to figure out what to download and how to configure his development environment.
Manager: Welcome aboard. Here's your desk, now make sure to ask around within the group to find out what version of Eclipse we've standardized on. Don't worry, we haven't added you to the schedule for at least a week or two. That's just how long it takes people to install everything, checkout all the code, and start contributing.
In the industry I've been working in, this is the norm. It takes days or weeks to come up to speed on a set of new tools, and you usually have to tease out information from a group of engineers who might not even be using the same tools or versions of source control. Even in environments focused on efficiency, installing all the software components that comprise a development environment still takes a surprising amount of time.
At Sonatype, we've suffered through this same inefficiency ourselves. Setting up a workspace to develop Nexus Pro or m2eclipse usually took a few days start to finish. Because of this, we created a developer onboarding tool called Maven Studio for Eclipse to dramatically reduce the amount of time required to setup a developer workstation. With this new tool, a new programmer who starts working on the Nexus project can get productive in a few minutes with all of the Eclipse plugins, project source code, and build infrastructure she needs preconfigured and ready to use.
Using Maven Studio for Eclipse, a build engineer can configure a custom Eclipse distribution and then publish Eclipse configuration to a new version of Nexus: Nexus Team Edition. Nexus Team Edition is a version of Nexus optimized for proxying P2 repositories and Eclipse Update Sites and designed to interact with our professional Eclipse product: Maven Studio for Eclipse.
When you use the Developer Onboarding feature of Maven Studio for Eclipse, a setup process that would have taken a few days is condensed into an automated process which takes a few minutes. Eclipse components, project configuration, and source code is all automatically downloaded during a process we call "Codebase Materialization". Build engineers can configure an Eclipse environment once, publish this configuration to Nexus Team Edition and distribute a simple URL to a team of developers. Developers then click on a link and walk through a simple wizard to materialize a workspace on a local machine.
Maven Studio for Eclipse is already saving Sonatype a considerable amount of time. If you are interested in saving time and learning more about Maven Studio for Eclipse or if you would like to take the product for a test drive, contact us for more information at: info@sonatype.com.