title: Arguments against a shared development environment
body: <p>So a constant headache at my current employer is that we (the devs) all share a common development 'test' environment.  The current process is as follows:</p>
  
  <ol>
  <li>Dev works on a piece of functionality on their working copy of the project branch</li>
  <li>When they are confident it works, test the change in the shared development environment</li>
  <li>Check it in</li>
  </ol>
  
  <p>So several obvious issues arise here:</p>
  
  <ol>
  <li>Since a lot of overlap occurs between projects, there is often contention for resources</li>
  <li>Since the changes are all manually put out there by a developer, the environment can be in a very inconsistent state (i.e. some services broken, others either newer or older than expected)</li>
  <li>When a developer is testing a service, they can often start and stop the service several times - when your work has a dependency on that service, you sit twiddling your thumbs awaiting them to resolve the issue</li>
  </ol>
  
  <p>I am trying to put together an argument to provide each project (trying for each dev would be shooting for the moon) with their own dev environment.  I am looking for what arguments I can make that will make sense to my manager (semi-technical, mostly business, bottom line focused).  Here are my current arguments:</p>
  
  <ul>
  <li>Delivered functionality against a known version of dependencies - makes deployment up the line easier</li>
  <li>Less competition for resources as the project teams are small enough (4-5 devs) that intra team communication is sufficient to allocate resources</li>
  <li>More development testing should catch more defects that would otherwise need to be found in QA</li>
  <li>Should drive out configuration details that are still hard coded</li>
  </ul>
  
  <p>These are good, but I don't think I have hit a home run yet.  If you want to make the opposite argument and provide me with some means of making my current environment a better place, I am open to that (though skeptical). </p>
  
  <p>Thanks.</p>