Building Dev Environments

Velocity as a measure of developer output is a well known metric for agile teams. Maximizing developer velocity is key to getting more code completed per sprint. But developers estimate more than just coding tasks in a sprint. In fact, “work to be done” estimates can encompass everything from documentation to investigations to maintenance tasks.
But should estimates also include build engineering?
From our recent Developer Survey, we know that 62% of developers start a new project at least once every three months. Leading/bleeding edge projects (for example, ones that employ programming languages new to the enterprise) require build engineering to create a brand new development environment. But even when using the same language for different projects, you’ll want to install a new virtual environment on a per project basis to avoid issues around dependency conflicts.
While some projects can leverage standard open source language distributions as part of their development environment, most projects will require at least some build engineering to tailor the open source language distro to the project’s needs. The required build engineering can either be a distributed effort that results in custom environments, or else a centralized effort that provisions a standard dev environment. For example:

  • Distributed & Custom: Developers build their own environment from a requirements file, using a proscribed method, or else
  • Centralized & Standard: Developers download and install a standard, pre-built environment.

 

Custom Dev Environments vs Standard Ones

There are pros and cons associated with each method. In the case of custom dev environments, where each member builds and manages their own dev environment, you can consider:
Pros:

  • Create a custom environment that results in peak efficiency and productivity with the tools you know
  • Discover environment-specific issues quicker
  • Fosters more experimentation

Cons:

  • Longer ramp up time to get to a working environment
  • Lots of “works on my machine” issues
  • Harder to apply changes/updates across the team

Obviously, when each of your team members is building out their own development environment, you won’t be getting much coding done in that sprint. For this reason, some enterprises allocate dev environment setup to a pre-project phase. Others allocate a sprint, with any leftover velocity used for initial project investigations. But what about maintenance of the environment going forward? Estimates will need to be done for not only patch creation, but also patch application, since a “one size fits all” patch is unlikely to work for all team members.
While some enterprises centralize build engineering in a dedicated build team, effectively getting their development environment “for free,” most do not have that luxury. Instead, one of the existing developers from the project team is given the task of creating a standard development environment for all team members. In this case, you can consider:
Pros:

  • Consistent environment across all team members (results in less “works on my machine” incidents)
  • Faster time to get to Hello World
  • Maintenance releases are easier to apply against a standard environment

Cons:

  • Diverse development environments can more easily uncover issues that are environment specific than a standard build
  • Single point of failure if the standard dev environment depends on one person
  • Steeper learning curve for new developers who have to use tools they are unfamiliar with/inefficient at using

Dedicating the building of dev environments to one or two team members frees up others to do research and investigation before the project starts. This approach minimizes the impact to project velocity.
 

Customizing Standard Environments

Unless you’re lucky enough to have a dedicated build engineering team, you need to include any work on your project’s dev environment in your software estimation.
Obviously, those estimates will be higher when each member of the team is installing and resolving issues with their own custom development environment. But the trade-off between custom and standard is one of time versus constraints. A single standard environment can feel limiting if you want to test out new library versions, or resolve issues with a specific environment, or implement your preferred tooling, etc.
One way to loosen constraints is to provide developers with a standardized environment that they can extend with a configuration management tool. Simply use the tool to initialize your dev environment with a standard configuration, but then also use the tool to add overrides specific to your environment as desired. Your overrides are stored next to the standard configuration, so anyone can see which changes have been made on any developer machine.
If a change benefits the project, those changes can be incorporated back into the standard configuration. This approach to build engineering accomplishes the consistency and speed of a standardized approach while still giving you the flexibility to experiment and work with your preferred tools. Furthermore, it creates a natural and easy workflow for updating the standard configuration as your team’s needs evolve.
 

Solutions

Tools like Boxen (from Github) have tried this sort of thing before. More recently, tools like Docker can be used to provide a standard environment, but allow room for modification post deployment through a config file, or else a new Docker image that extends from the original one.
No matter which way you choose to go, the ActiveState Platform has been designed to help you minimize the time and effort to create the open source language build that goes into your dev environment. With the Platform, a single person can now accomplish in hours what it used to take a team weeks to create.
To give the ActiveState Platform a try, sign up and create your free account today.