I'm trying to convince my co-workers about the merits of developing on local environments, but so far have had little luck in my quest. Outside of myself, the other developers with my company develop on seperate folders on the same server as our development server, using the same DB/DB Server/Web Server for all folders, with your standard text editor on the local machines. I've mentioned the benefits of any mistakes (like say the stray while loop misconfiguration) localized to one machine, network or server issues having no relevance or effect on work, and able to use xdebug (although you can use it on a shared server, the issues with sessions I've been told are problematic...and not having a fulltime sys admin to keep things happy doesn't hurt either). So far, no dice.

So I ask you the SO community what could be done to convince others to do so, or if I'm the one that is on the wrong path. The current environment that we have is your typical WAMP environments, but I wanted to keep the question language and environment agnostic as possible.

Thanks in advance!

  • 1
    Do you use a source version control system? Just wondering, because most are based on the idea that you check out your work to a local machine. This makes it more flexible to do dev, test, and build without breaking the main dev and test servers. OK, for some systems that won't work of course, as you HAVE to dev on the server - but for most web projects, local dev works fine (if a version control system is used)... Jul 21, 2011 at 3:29
  • Yes we currently use SVN, and your'e right, those are some good reasons to use local dev environments that I've tried to illustrate, with limited success as this question illustrates. Jul 21, 2011 at 10:19
  • In that case MerryPrankster already pretty much said what I'd say to this :) That is, until you can come up with a compelling business case for local dev, that your can successfully sell to your manager(s). Jul 21, 2011 at 14:26

5 Answers 5


Use a local environment yourself. I guess you've tried evangelizing, now don't. When someone asks why you doing it, or what are your experiences with your arrangement, explain them. If you get a convert or two, rest will probably follow. If nobody sees the benefits, there either aren't any (I doubt), or you really should look for a new job..

  • I do as mentioned in my original writeup, but you are correct in that you should practice what you preach. Jul 21, 2011 at 11:59
  • 3
    Just keep evangelizing. Be especially snotty when one of them is having trouble debugging something that could be debugged locally in minutes. Or when an error ripples out because its not contained locally. I myself initially learned programming from a PHP/web sorta model and thought my .NET developer coworkers were wasting time by developing their apps locally. Didn't take me too long to see the power in what they were doing.
    – GHP
    Jul 21, 2011 at 17:00
  • Or when someone breaks the environment and you are completely uneffected by it. Jul 2, 2014 at 13:56

Don't worry about what they do. It will just make your head hurt. However, if I were you, I would be looking for a job, or at least a different position. You are not compatible with this team, and your frustration will only increase.

  • Unless you're the technical director of this company, or married the boss' daughter then kevin cline has the way of it. It's an uphill battle and you're only going to lose. Jul 21, 2011 at 5:17
  • 1
    While you have a point, it's one that is a "last resort". Jul 21, 2011 at 10:20

OK, I'm being half serious here...

Create your local dev environment, and crash the dev server.

You probably shouldn't really do that, but it would be the most effective way of demonstrating the benefits of a local dev environment. While they're busy mucking about with the server, unable to do any development work, you can point out that you can still be productive.

  • Ironically that is what happened today, so umm...mission accomplished? (did not crash it, but the timing was interesting to say the least) Jul 21, 2011 at 17:59

It sounds like it should only have a minimal impact on your own work. If so, I would let it go. There are benefits to a shared development environment as well, such as quicker sharing of code, easier backups of work in progress, less hardware expense, easier to standardize the environment, less setup and maintenance time for individual developers, etc. Different people have different preferences for how they like to work, and there's nothing wrong with that.


Typically the reason you have an entirely separate system is so you can alter shared libraries.

On your common development environment, you will almost certainly have something that is common to everybody, a system service or a version of some component (eg a database) that cannot be changed. So when you want to make changes to that shared component,everyone else is impacted until you're done, and even then - you simply cannot revert to an older version of the codebase without reverting (ie re-installing) the shared component.

On your own dev box though, you can do what you like without interrupting the guy doing bugfixes on the old code, or the guy just updating a feature that uses the existing system.

For example, at an old place we had a few PHP devs who coded on a shared linux box that was 'controlled' by a sysadmin guy. All was good if they only updated application code (which they could do in their home directory), but there were some shared services that could not be updated... and so never were, ever. When it eventually came time to update the OS, one dev had a new box built for him and everything migrated so he could make whatever changes were required - notice that this is effectively a box for himself, a situation that wouldn't have been as disruptive as it was had he been running locally anyway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.